rorum 


NFC Digital Protocol 
Technical Specification 
NFC Forum" 
DIGITAL 1.0 
NFCForum-TS-DigitalProtocol-1.0 
2010-11-17 


RESTRICTIONS ON USE 


This specification is copyright O 2005-2010 by the NFC Forum, and was made available pursuant to a 
license agreement entered into between the recipient (Licensee) and NFC Forum, Inc. (Licensor) and may 
be used only by Licensee, and in compliance with the terms of that license agreement (License). If you are 
not the Licensee, you may read this Specification, but are not authorized to implement or make any other 
use of this specification. However, you may obtain a copy of this Specification and implementation rights 
at the following page of Licensor's website: http://www.nfc-forum.org/specs/spec license after entering 
into and agreeing to such license terms as Licensor is then requiring. On the date that this specification was 
downloaded by Licensee, the non-implementation terms of that license were as follows: 


1. LICENSE GRANT. 


Licensor hereby grants Licensee the right, without charge, to copy (for internal purposes only) and share 
this Specification with Licensee's members, employees and (to the extent related to Licensees use of this 
Specification) consultants. This license grant does not include the right to sublicense, modify or create 
derivative works based upon the Specification. 


2. NOWARRANTIES. 


THE SPECIFICATION IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
OR IMPLIED, INCLUDING BUT NOT LIMITED TOWARRANTIES OF MERCHANTABILITY, 
FITNESS FOR A PARTICULAR PURPOSE, ACCURACY, COMPLETENESS AND 
NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL LICENSOR, ITS 
MEMBERS OR ITS CONTRIBUTORS BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, 
INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING 
FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, 
NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH 
THE USE OR PERFORMANCE OF THE SPECIFICATION. 


3. THIRD PARTY RIGHTS. 


Without limiting the generality of Section 2 above, LICENSOR ASSUMES NO RESPONSIBILITY TO 
COMPILE, CONFIRM, UPDATE OR MAKE PUBLIC ANY THIRD PARTY ASSERTIONS OF 
PATENT OR OTHER INTELLECTUAL PROPERTY RIGHTS THAT MIGHT NOW OR IN THE 
FUTURE BE INFRINGED BY AN IMPLEMENTATION OF THE SPECIFICATION IN ITS CURRENT, 
OR IN ANY FUTURE FORM. IF ANY SUCH RIGHTS ARE DESCRIBED ON THE SPECIFICATION, 
LICENSOR TAKES NO POSITION AS TO THE VALIDITY OR INVALIDITY OF SUCH 
ASSERTIONS, OR THAT ALL SUCH ASSERTIONS THAT HAVE OR MAY BE MADE ARE SO 
LISTED. 


4. TERMINATION OF LICENSE. 


In the event of a breach of this Agreement by Licensee or any of its employees or members, Licensor shall 
give Licensee written notice and an opportunity to cure. If the breach is not cured within thirty (30) days 
after written notice, or if the breach is of a nature that cannot be cured, then Licensor may immediately or 
thereafter terminate the licenses granted in this Agreement. 


5. MISCELLANEOUS. 


All notices required under this Agreement shall be in writing, and shall be deemed effective five days from 
deposit in the mails. Notices and correspondence to the NFC Forum address as it appears below. This 
Agreement shall be construed and interpreted under the internal laws of the United States and the 
Commonwealth of Massachusetts, without giving effect to its principles of conflict of law. 


NFC Forum, Inc. 
401 Edgewater Place, Suite 600 
Wakefield, MA, USA 01880 


Contents 


1. INtFOCUCHIONs br E 1 
1:1. een 1 
CM ele 1 
1.3 Applicable Documents or References AAA 1 
L4. eu E Let E 3 
15. “Nameand Logo Usage... eter aee e d det te e dee e egi edet 3 
1:6: -Itelléctüal;Ptoperty:....5 rn eorr eter eni tte Ree ne Re a ra ie ete ease e oret 4 
L7. Acknowledgements... eet eerte ee eee pee cere ree coe d ee Rare EES 4 
18 Special Word Usage ........ iiie teeth eene reete te tete ctr Do da ra eed deua 4 
19 Requirement Numbering ................ccscssscsscceeccssscsescsenceensesnscsesscesscesscessessceesceseseseneeees 4 
1.10 Implementation of Optional Items.................... esee ener enne enne nnn nnns 5 
1.11  Notational Convention. 5 

1.11.1, ANOtatlOTS: ione rene eee nee RENAE ERA eee ERE N ERE e ERE NEEN AEN 5 
L1L2 -ValueofParámetelts;.... eec ere mee terr dw tese 5 
LIZ Abbreviations RTT————————————— Ó 6 
1,13. GLOSS APY he ee nre eie esee eto e eee eee eere Fes rene HP Ger evertere ps 8 
1.13.1 Device and Commumnicaton,. 8 
1:13.2. - Protocol and. Mode... erret teuer tee i eret ean 10 
1:13:3- Errors noe eene en eer dee e tetra ever te Ye eerie Ec Yen 10 
o iul eve 12 
[Jj REENEN EEN LA 
e INEC-A e E el e EE 15 
4.1 Seguente Format... cec mehr tere pene ere Ree e Eee te eel ee od ERR ee E EE EU ee eo EEN 15 
4.1.1 Poll Listen Modulaon enne enne enne 15 
4.1.2 . Listen Poll Modulation ......... ccc ceeccesscessceesceeseeeeceeneeeneecneecseecneceaeceaeeeaeens 17 
4.1:3 Synchronization eene retener Let eese ier tbe tereti 18 
4.1.4 ` De-Symchromization..............csccssscssscssscssccesccssscssncsencsensesnsssnsssesscenscensceesseseees 19 
42;  BitLevelGoding... nece nate nee rere rere re redes eret eg 19 
4.2.1 Poll Listen Coding Scheme esses nennen enne 19 
4.2.2 Listen Poll Coding Scheme esee enne 21 
d» JBrapme:jEOFAE:S coser eerte EE atre etes e ah ety ede tee ape cere a ee SEDENS Ue Pete ee tue Estes 21 
4.32: - "Short H LEE 22 
4.3.3 — Standard Fràaimne.....i.iiue tecti estere eire rete ais eari denn 22 
4.3.4 | Bit Oriented SDD Frame eene 23 
AA. Datz and Payload Format... uuo eter erret e EH reete reed 24 
4:5: -Command TE 25 
dp: ALL REQ and SENS REQ 4 eee esee tee err EEI Ar E AEEA SEA E EE TaS 25 
4.6.1 ALL REO Comnialid...... a tectorio r aa a ewe 26 
4.6.2 SENS -REO:Command..:.:45.::. eerie toe EA Eee ed 26 
4.6.3 SENS RES Response... eee tere Heer rer PEE ee 26 
AP? SDD REQ MT" -————————————————HMH—— — M — 27 
4.7.1 SDD “REQ Command ;.. cde d begleede beer eyes 28 
4.7.2 SDD. RES en 31 
BCEE EE RE 34 
4.8.1 SEL REQ: Command. enne ettet ete 34 
4.8.2 SEL RES: Response; aired ere REPH RH UE ERE EE Eed 35 
49. -SEP REQ suci repere reet eie He e e OPER Rev Te ORA bake oo RE LR Ee des 36 


NFC Digital Protocol Page i 


4.9.1 SEP-REQ:COmEInDand: 5. iet hain haves sce voce ess 36 


4.9.2 SEP- REG Response... m cde CU RERO CUR D E RR ERR ERE RO Co 37 

4.10 - Timing Requirements .......... eee rere teret reote ree beri Ee pleniter aane en 37 
4.10.1 Frame Delay Time PollListen....................... eese ener enne 37 

4.10.2 Frame Delay Time Listen Doll. 40 

4:10:3- C Gard DIle $2 op rettet ree etie teet de tee e eoe e et eget tee 42 

5 NFC-B Technology siti sece sect tm 43 
CL .:Sequence Format... endete PIRE ERAI 43 
5.1.1 Poll Listen Modulation 0.0.0.0... ee eeceesseenseenceececeecseeceaeceseceseeeeecseeeeeneeens 43 

5.1.2 ` Liisten—>Poll Modulaon essere nennen enne nnne nnne 44 

5.173: - Synchrónizati oM tne etr leet eerte Hee tee rU DE e ol eee 45 

5.1.4 Pattern Senchrontzaton. esses enne enne nennen nennen 48 

5.1.5 ` De-swpnchrontzaton.. eene ener enne enne 48 

5.2. Bit Level Coding... detenti ere eee ite Certes e roe edere eta eere oe ead 50 
5.2.1 Poll Listen Coding Scheme esses eere enne nnns 50 

5.2.2 Listen Poll Coding Scheme eese eere 50 

5:297 - Framé ojus 51 
5.4 Data and Payload Format. 51 
5:51 Command Set i. n a tre E o eter pe E a A Nre 52 
5.6 | ALLB REQ and SENSB REO, ............. eese ener nete i eni siteres issie ii 52 
5.6.1 ALLB  REQ and SENSB REQ Commande 52 

5.6.2 SENSB:.RES Response veuria a terrier eel eee eere Ree epa rene 55 

Def SEOTF MARKER: eene re HDD oi tent eee pa ee tese rs 62 
5.7.1 | SLOT MARKER Commande 62 

5.7.2 SLOT MARKER Responge AEN 63 

5:8 . SEPB REQ «nicer eee rem e e Penn tenes 63 
5.8.1 SLPB REQ Commande 63 

5.8.2 SEPB RES Resporise ........ diee eee dee edere ENNEEE Nees 63 

5:9. Eimine Requirements... eorr erede teret ere e e tede tete rae eta eie gae ee 63 
5.9.1 Frame Delay Time Poll Listen... 63 

5.5.2 Frame Delay Time Listen Poll... 66 

5.99.3. . Guard WR LEE 68 

6; :NEC-ETechBologyiis iiid iioii iid besides 70 
6.1. "Sequence:Pormat. 4n oreet etre eee entere te bei ht eo pee erecti edes 70 
BLL (Modulation: ccs. ar tene EC RE e 70 

6.2. Synchronization... cete rette teer Eee eo Eee eie i teer tier 71 

6.1.3  De-synchronizatioOn.............. eese eene nenne eene nene nn seen ne tn nennen enne 73 

6:2. .JBitLevelCoding:..:5. nc niet tei dits cate m e rU Pee ae ees 73 
kä: .Prame:EOFnaE. eicere erg tere eee dr t ele ie Oe ehe Poen tee ee e eese dh 73 
6.4 Data and Payload Format. 74 
6:5. Command Satire ner re tet ene essere see HEP RE VERE ek andes EE ene eventos 75 
6:6: .:SENSE-REQ une emt emn SU URGE RERO GR 75 
6.6.1 SENSE RECO Gommand.:.:.: eite teet a e cete e sees eae 75 

6:6:2 SENSE- RES. ReSpons@ noiseen rie eret a teaa i e eet eden n 78 

6.7 "Timming:Requirements. o eicere eerte de fete age te eg ete at ve dose te eo ee ee n gea 83 
6.7.1 | Frame Delay Time Poll—.Listen..................... e eeeeeeeseeeeeeeeeeee teretes 83 

6.7.2 Frame Delay Time Listen Poll... 85 

MEE CI MEINT 87 


NFC Digital Protocol Page ii 


7 Half-duplex Protocols usage —— nnna 88 


8 Type T Tag Platform WE 89 
8.1. -Següence Format... one e reete ER Ree I ENEE a EErEE ERE HERR SE E AE 89 
8[2.  BitLevel EE 89 
8:3- “Frame Formaten oops Pee ie terere tet ete E a A eatenus 89 
8.4 Data and Payload Format. 90 
8:5: “Command Set: route nemen cen c A tite e leere ras 91 
8:6: .Readldentüfier (RID) ...... eere ert mom eret e eee ERR E Eve Eee ES 92 

8.6.1 — RID Command... EE 92 

EEN CBR ET 93 

8:7 . Timing Requirements 5... eere nere iere edere oo eon eb ee ete edes 93 
8.7.1 | Reader-Reader Data Delai 93 

B.752- Frame Délay Time... eret cri etuer Eee Re Ee Ehe 94 

9 Type 2 Tag Platform -uurisin ianei nin ainiaan in aaia iaiaaeaia aaia ai 96 
Sequence: Bormat. (sete rete EEA Pere i rte Ep E AE 96 

9 Bit Level. Coding... ene rore ter E v e dert ede ee 96 
23 Frame: o] uie ———Á 96 
9.4 Data and Payload Format. 97 
E WE e ene 98 
9:6; -READ idee ene PCR HR HE d RERO E ae ne 98 
96 Goran «eset bien erede ere tei eter ee ege te ewe 98 

ERAN A DAI MR 98 

9.7  "WREEE 5S EEUU n OE n ee 99 
9.7.1. e eu BE 99 

KEE WE Ten 99 

9:87 1 SHE TOR SEE Cee edicere ei dee ee e e e ute IRE TOR aS 100 
9.8.1 | SECTOR SELECT Command Packet 1 ...................... eese 100 

9.8.2 | SECTOR SELECT Command Packet 2 ................. essen 100 

9:8:3 RESPONSE e ——————————— — 100 

DH ` Drone Requirements... nein eret ree eroi rie beet rene reda 102 

10 Type 3 Tag Eltere eebe eege eege 103 
10:1; Sequence: Formats 2... 2 eie etie ea eee D pendent Ree E otras 103 
10.2. "Bit Level. Coding... cte ette etre ete oe ER EEN E ELE PUE EC CU ER tke 103 
10.3- Frame Format 5. nahe ne He eene ther e erbe eerie ees 103 
10.4 Data and Payload Format. 103 
10:5. eene 104 
10.6 pret EA UE EE 104 

TI Type 4A Tag Platform... oe i eee nere eet rione nones cere oec 106 
RW lee EE 106 
11:2: ; [Bit Level ee 106 
1L3. Frame Format... en M oe ee es 106 
11.4 Data and Payload Format. 106 
RE gea 107 
11.6 Request for Answer to Select (RATS).. 107 

DT RATS Command... erre er E CER CHEER ee tasers EHE HR 107 
11.6.2 RATS Response (Answer To Select), 109 
Ne Rent ut Uu ET 115 
LEAL FW eines ener Aad Aaa need a 115 


NFC Digital Protocol Page iii 


TE A 2- (SEG EE 117 


12 Type 4B Tag Platformi naa ce ea raa niin econ 118 
UE e ENTREE 118 
12:2. Bit Level Coding ........ eei tenere tete t n ER eerie ae i eaa te de a CREE de CR ede 118 
12.3. ‘Frame Format... ente emen ERG e e EA dee ee 118 
12.4 Data and Payload Format. 118 
12:5- Command Sether inira debe en Get sees oto E EO epe tete Eee e eios 119 
12:65 "ADI RIB eere pete eet ee e eee ertet eere nde eech 119 

12.6.3; ATTRIB Commard...... pnr tret rre nia ten e RR ee Tee 119 
12.6.2, "AUT RIB:RéSpOHSE: ien eoe E EIE REPERI RE EROR 125 
12:7 mung:Requirements..... iere reti terrre rer rre ree reri Peer roS 127 
13 1SO-DEP Protocol ec 128 
13.1. "Block Oe nei rir teet teh eer EE ee EE o PEE Ekeris T terea Rakas 128 
13.LhlL Block. tete eere te oe ee niteat 128 
13:127 (SOD c ctr i ere A re e Pr Pe E Da 129 
S EM VI ———Á—— 131 
13.L.4.. EOD sn nene e Pn ee e eve ge Red 131 
13:2. Protocol Operation... eere rece eee pes teet ere tee pepe es 132 
13:24 General Rules... 4... ctt eene nente eret ear Pec na iisi 132 
13.2.2 Frame Waiting Time Extension... 132 
13.2.3. “CHAIN Gs sso, e erdt Rer ee PR Pe Eee ee ertet 135 
13.2.4 Block Numbering Rules A 135 
13.2.5 Block Handling Rule... ccssscesscesscesccssccsescsencsencesnsssnsssesscensceesenesens 136 
13.2.6. Exception Processing... eee teens tr cdcotevecsaesanccedanssecdbestecces 138 
13.2.7  De-activation Rules............:cssscssscssscssscssscssscssccssscssncssnscsnsesnsssenscenscesssnesens 140 
I3.3. Timing Requirements eesriie eerte eterne eese er Iber ERE e FERRE Repeat 142 

det NEC-DEP ui cse ——— (€ 143 
14.1. :Sequence Formats 4 cain enero etre Rte P REESE 143 
142- "Bur Level Coding. 5er ero ente mer e pe e ie eei 143 
14:3- :Brame;borrmat:. 4 oet n ert Pe ree E ree ertet e inr e ertt ER 144 
14.4 Data and Payload Format. 144 
14:5. eu 145 
14.6 Attribute Request (ATR, REO.. nennen nennen enne ennt enne 146 

14.6.1. ATR REQ Lengtli........... eerie reet treten eo eno tee ae eae nena en 146 
eh -ATR:REQ: Comniand.......:.: 3: eicit hehe hr e tere erbe t tea 146 
Jet -ATR RES | BeSpOLDSe....z6 erret er zero rene eet eer EPI ec 149 
14.7 Parameter Selection Request (DS. REQ)................. essen enne 152 
14.7.1, :.PSL:REGQ'GComnmand.: rne ee erre eere Meare teet dee ten 152 
E ET EE e EE 154 
14.8 Data Exchange Protocol Request (DEP REQ).................. eese 154 
148:1. .DEP':REQ: Command... ette cre tpm ee re i tee er rop even 154 
14.8.2- "DEP RES: Response; oe eerte I Pee cte a ee e e rte Rer eds 155 
14.8.3 Protocol Format Byte (DER)... 156 
14.8.4 Response Timeout Evtenston. 157 
14.9 Deselect Request (DS. RO)... 159 
14.91 DS: REQ Command... rome rere ee ro EA 160 
149.2 DSL RES: Response ;... reunieron 160 
14.10 Release Request (RLS. REOI, eene eene enne entente reset 161 
14.10.1. RES REQ Cotmmarld.........::. rtr erre ceret ee et eee e eo re Fre ere Eg 161 


NFC Digital Protocol Page iv 


14:10.2. RES RES Response ....... eerta et reed al ere ent 162 


l14.LL Rent et Uu EE 163 
14.12 NFC-DEP Protocol Operation ............ccsccesscessceeceeeeeseeeseeenseceecsaecsaeceseceseceeeseeeeeneeees 165 
14.12:1. General RUES. neteis eetri Taie oe rete e eet ee Ee dte te Ie He shh 165 

Id peine ——MÁÀ 165 

14.12.3 PDU Numbering Rule... 166 

14.12.4 PDU Handling Rules nennen enne enne enne 167 

14.12.5. Exception Processing........:..... e eee aoise sien reae i eiii eise aeii 168 
E ET 170 
A.l  NFEC-A Technology. inicirao airis ns AE esie bene eed 170 
A, CNFC-B Technologyn ienna eter t eee ten eet t re P e N dn 171 
A3. INEG-E-LéchnoloBy. x... iré erre HP rere reete Her bee P ee 172 
Aya’. “Typed Tàg Platform... eter tent ere eere ree dete ENEE 172 
A:5-. Type 2 Tag Platform... erem trece nt ene EE EE EP ee eg 172 
AG: "Type 3 TàgPlatform...5.: e cere eee er eee eO me e eae deans 173 
A7  "Type4A Tag Platform... eee ottenere eee Re siisii teinte rine cha Le 173 
A;8: "Iype4B Tag Platform... deir e rhe eer he E eed 173 
A:9.- ISO-DEP:PrOtOCOl aia tetti e Per ee Ee Pepe ERE TES 174 
A:10: "NEG-DBEP'ProtGG0L.;;.. tiit ote other ree re eee etti ee ei ere ego 174 

B- REVISION FISIOFY E SEENEN SEENEN NENNEN NEEN 175 


NFC Digital Protocol Page v 


Figures 


Figure 1: 
Figure 2: 
Figure 3: 
Figure 4: 
Figure 5: 
Figure 6: 
Figure 7: 


Figure 8: 
Figure 9: 


Figure 10: 
Figure 11: 
Figure 12: 
Figure 13: 
Figure 14: 
Figure 15: 
Figure 16: 
Figure 17: 
Figure 18: 
Figure 19: 
Figure 20: 
Figure 21: 
Figure 22: 
Figure 23: 
Figure 24: 
Figure 25: 
Figure 26: 
Figure 27: 
Figure 28: 
Figure 29: 
Figure 30: 
Figure 31: 


Modified Miller Coding with ASK 100926...................... eese 15 
Manchester Coding with OOK A 17 
suadent 22 
Standard Frame (Poll—Listen Communication) ..................... eese 22 
Bit Oriented SDD Frame (with Split after the First Bit of the Second Byte) ................ 23 
Data and Payload Format — NFC-A Standard Frame. 24 
Example: SDD  REQ with 14 Data Bits of NFCID1 CL1 (4 Bytes Size) and SDD RES 
speci dered guste ves cde ——Ó————Á—M—Á——————— — —À— 33 
EDDA EE 38 
tinmi LOR NECA ER —Ó—— 40 
EDT 0r: deer EE rere RO EHE EE EEA 41 
KE EE 43 
NRZ-LE. Coding with: BPSK oneitan nenn npe e hte E e RO qp Dee 44 


Synchronization and Timing Parameters between a Listen Frame and a Poll Frame.. 45 


Synchronization and Timing Parameters between a Poll Frame and a Listen Frame.. 46 


NEC-B = Character e E Soet TEI a eiee Soa PERNES EAE See 51 
NF@=B = Brame: Format... ede hein rtl e P re R a 51 
Data and Payload Format — NFC. 52 
E E Mu E 66 
Manchester Coding with ASK Modulation .................... eese eren 70 
Signal Synchronization and Timing Parameters ......................... eese 72 
NEC-E = Character Format edet terga irte eet iir atop ate oi 74 
NEG=F = Brame: e EE 74 
Data and Payload Format — NC. 74 
Collision Resolution (sample), 78 
Frame Format — Type 1 Tag Platform in Poll Mode.............................. eese 89 
Data and Payload Format — Type 1 Tag, 90 
Reader-Reader Data Delay (RR DD)... 94 
Data and Payload Format — Type 2 Tag (except for ACK and NACK Response)...... 97 
Data and Payload Format — Type 4A "Tag. 107 
Isle ein) —————À— 128 
Data and Payload Format — NFC-DEP Protocol....................... eese 144 


NFC Digital Protocol Page vi 


Tables 


Table 1: IO NEE 4 
Table 2: Notational Conventions.................. eese eeeeeeee eee ennt entente enne enne then etne tentent nete 5 
Table 3: Activities versus Technology / Device Plattform... 13 
Table 4: NFC-A — Command Set .................... eee esee eee eeee eset netn ettet ne entente trata eo tette tn ntn Ven 25 
Table 5: Format of ALL RO... 26 
Table:6: Format ot SENS REQ. eth titt tee Peer tei eet eite e pd Eee cett dee 26 
Table 7: Bytë Tof SENS RES... onte eee n ne e m i ene een eie doesnt 26 
Table8::Byte 2:0P. SENS? RES: ed n ee re tyre ege te see 27 
Table 9: Format of SDD REQ Commande 28 
Table-10::Format of SEL CMD, sek nere ete riter reino Peine eee rester REENEN 28 
Table 11: Format of SEL. PAR (Upper 4 Be). 28 
Table 12: Format of SEL. PAR (Lower 4 Bits)................. esee 29 
Table 13: SDD. RES Response (NFCID1 CLn + BC, 31 
Table 14: nfcid1, for Single-size NFCID1 A 31 
Table 15: Format of SEL REQ Commande 34 
Fable: 162 NEGIDT GET... enn D ee deer Ee eee eon 35 
Table 17: Format of SEL. RES Response ............:sccssscsseceseceeceeceeceeseeececeneeensecseecseecsaeceaeceseceseeees 35 
Table 18: Format of SLP REQ Commande 36 
Table 19: FDT usren and Logic State of Last Data Bin... 38 
Table 20: FDT tere we ANd Command Type................. eese enne enne enne nnne teen 38 
Table 21: NFC-B — Command Set EE 52 
Table 22: ALLB REQ and SENSB. REQ Command Format. 53 
Table 23: Format of PARAM Byte Included in ALLB_REQ and SENSB. REQ Command ....... 53 
Table 24: Coding: of EE 54 
Table 25::SENSB: RES Fotmat, erret nere eie ri e ee ver Ee eed 55 
Table 26: Application Data Format. 56 
Table 27:;Protócol Info: FOEmat:..7. 4 inet ee et ihre rit e gets REESE pee eg 56 
Table 28: Bit Rates Supported by the NFC Forum Device in Listen Mode.................................. 57 
Tàable:28:; ESCLIto:ESG GOnBVBISIOD;.;. eie erint tapete be ete eene DEENEN ente 58 
WTable:30::Protocol Type: ete rtr rer HE HE Pe HUP CE ease YER sarees EE 59 
Table-31: Minimum TR2 Coding... nee reser edes reete serie ee sire to rie tegere cus 59 
Table:32: ADG Coding «eet rene rer ee eere Reeve ew ie edu 61 
Table 33 FO = NAD ET 61 


NFC Digital Protocol Page vii 


Table 342 FO —DID;.z bend etn det e i ee n e das mee deer diete dive 61 
Table 35: SLOT MARKER Command Format. 62 
Table 36: Coding of Slot Number... AAA 62 
Table 37: Format of the SLPB REQ Commande 63 
Table 38: SLPB. RES Response Format. 63 
Table 39: NFC-F — Command Set.................... eee eese eeseeen ette eene e aa tnnt teen tnis 75 
Table 40: SENSF REQ Command Format. 76 
Table 41: Coding Of: RG zie rentre erae dene eere eter entre dient diuo 76 
Table-42: Coding Of. TSN uice iter desee tere ie ute ee etae ie Seege EEE EA EO D 78 
Table 43: SENSE. RES Format... tie teet edere eti E Ue e Rp te rien ae ene dS 79 
Tàable:44: NFCID2' Format... ees Ree RR ee edere err ner ege ERROR 79 
Table 45: RD Format Advanced Protocol Features (Byte 18) ................... essen 82 
Table 46: RD Format Advanced Protocol Features (Byte 19) ................... sese 83 
Tàble:47: eet ee TE 92 
Table 48: RID Command Format... 92 
‘Table:49: RID Response Format ..-....:... eintreten ertet ee eee deeg DEE ee ke de rese EE 93 
Table 50: Command Bet ege ée ertet te e ei ee e a E ER P Ree b hin 98 
Table 51: READ Command Format. 98 
Table 52: READ Response Format ...............:sscsscsecsercessesotcocesscnoccosesncecetoetencenseserscconecuessnseenensenoes 99 
Table 53: NACK Response Formats nnum neinni ann iii an e aa E eas 99 
Table 54: WRITE Command Format. 99 
Table 55: ACK Response Format. 100 
Table 56: SECTOR SELECT Command Packet 1 Format. 100 
Table 57: SECTOR SELECT Command Packet 2 Format... 100 
Fable a8! Comimatid: Sets ee Re RR Heer rte Re Ueber eee ERR 104 
Table 59: Format of MRTIcugck and MR Tluepare,. eerte enne 105 
Table:60::Commiarid'Set,....... si. erre rep rr EP e diee eee ree er e p ee eege 107 
Table 61: Format of RATS Command AE 107 
Table 62: Format of RATS Parameter Byte (PARAM) ............... essen enne nnne 108 
Table 63: FSDI to FSD Conversion .................... rore arden e etes nn e E teet ns tnn testen 108 
Table 64: Structure of the AT Serrone erna a a E E T E E Re 109 
Table 65: Coding of Format Byte "TO... 110 
Table 66: FSCI to FSC Conversión eini er eN E AEAEE EET EE TSA 111 
Table 67: Coding of Interface Byte TA)... 112 
Table 68: Coding of Interface Byte TDBO).. esee eene enne nennen nenne 113 


NFC Digital Protocol Page viii 


Table 69: Coding of Interface Byte TC)... 115 


Table:70: Command et niente te perum edente ene tra ee te ER rhe eve eL ain derer th PER eee ERE 119 
Table 71: ATTRIB Command Format. 119 
Table 72: Format of Param 1 of the ATTRIB Commande 120 
Table 73: Format of Param 2 of the ATTRIB Commande 122 
Table:74: FSDI to FSD Conversion sinnsirean n ie aa i e oa 122 
Table 75: Coding of bü and b7 of Param 3. 123 
Table 76: Coding of b6 and b5 of Param 2 .............. sese eese enne nennen ennt ternera en 123 
Table 77: Format of Param 3 of the ATTRIB Commande 124 
Table 78: Format of Param 4 of the ATTRIB Commande 125 
Table 79: ATTRIB Response Format, 125 
Table 80: Format of I-block PCB urenset roia tne teet n sente thes riii 129 
Table 81: Format of R-block PCB...............ssscscsssssteccenscneccoseescecesoetencensesensoceseeneccotessensetoesenseners 129 
Table 82: Format óf S-blockPGB earth ert op irte EE rer epe yet y 130 
Table 83: Format of DID Field......................... eese eeeseeeesesee enne ai i alari eri ein 130 
Table 84: Format of INF Field of an S(WTX) Request ........:..csccesscessceseceeeceeseeeneeeeeeeneeeseecseecseees 132 
Table 85: Format of INF Field of an S(WTX) Response ..........:..csccessceseceesceeeeeeseeeeeeeeeeeneecseecseees 133 
Table 86: NFC-DEP Protocol - Command Set................. eese entente enne 145 
Table 87: ATR. REQ Format. 146 
Table 88: Bit Rates Supported by Initiator in Sending Direction (BSj) ...................................... 147 
Table 89: Bit Rates Supported by Initiator in Receiving Direction (BRj)................................... 147 
Tablé 90: PP: EOtrmat; en ege Ee ee elected 148 
Table 9T: ER E 148 
Table 92: ATR-- RES Förmat. enero E SEENEN OASE 149 
Table 93: Bit Rates Supported by Target in Sending Direction (BS;)....................................... 150 
Table 94: Bit Rates Supported by Target in Receiving Direction (BRr) .................................... 150 
Table 95: LO e EE 150 
Table:.96: PP: EOFIIldE eret oe rete ees recte e eetes ore tet temet et geegent mee exe ée EEN 151 
Table 97: LR4 Coding .......... eee deti er era ona et eere ene i ares s n 151 
Table 98: Format of PSL REQ Commande 152 
Table 99: Format OL, BRS erret petere ono ERE CHEERUE T a pese cer EAR eee e e re Nee rts 153 
Table 100: Coding of DSI and DRE cnocie iere eee ener te tenentes ennt iaia 153 
Table:101::Format of ESL: oett ern eerte teen eterne etras xev E ege 153 
Table 102: Format of the bal RES Responsge essen eene nne nen eterne sterne 154 
Table 103: Format of the DEP. REQ Commande 155 


NFC Digital Protocol Page ix 


Table 104: 
Table 105: 
Table 106: 
Table 107: 
Table 108: 
Table 109: 
Table 110: 
Table 111: 
Table 112: 
Table 113: 
Table 114: 
Table 115: 
Table 116: 
Table 117: 
Table 118: 
Table 119: 
Table 120: 
Table 121: 


Table 122 


Table 123: 
Table 124: 


Format of the DEP. RES Response .......s.ssseseseesssseesseserssessessessessresseseesseseessesressessesses 155 
PFB Coding of Information DUDU... 157 
PFB Coding of ACK/NACK DD... 157 
PFB Coding of Supervisory PDU ................sesessesseeseeeeeeee eene enne enne 157 
Coding of Transport Data Byte of an RTOX Request .............. esee 158 
Format of Transport Data Byte of an RTOX Response ................. eese 158 
Format of the DSL. REQ Commande 160 
Format of the DSL. RES Response 160 
Format of the RLS REQ Commande 161 
Format of the RLS RES Response eese eene entren ennn enne 162 
NFC-A Technology Poll Mode and Listen Mode Parameter Values ........................ 170 
NFC-B Technology Poll Mode and Listen Mode Parameter Values ........................ 171 
NFC-F Technology Poll Mode and Listen Mode Parameter Values ........................ 172 
Type 1 Tag Platform Poll Mode and Listen Mode Parameter Values ...................... 172 
Type 2 Tag Platform Poll Mode and Listen Mode Parameter Values ...................... 172 
Type 3 Tag Platform Poll Mode and Listen Mode Parameter Values ...................... 173 
Type 4A Tag Platform Poll Mode and Listen Mode Parameter Values.................... 173 
Type 4B Tag Platform Poll Mode and Listen Mode Parameter Values.................... 173 
` ISO-DEP Protocol Poll Mode and Listen Mode Parameter Values .......................... 174 
NFC-DEP Protocol Poll Mode and Listen Mode Parameter Values......................... 174 
Revision BISON ziii reitera re rere tet ere ee saves Bett eere te PER ee EOD TER 175 


NFC Digital Protocol Page x 


Requirements 


Requirements 1: 
Requirements 2: 
Requirements 3: 
Requirements 4: 
Requirements 5: 
Requirements 6: 
Requirements 7: 
Requirements 8: 


Requirements 9: 


Requirements 10: 
Requirements 11: 
Requirements 12: 
Requirements 13: 
Requirements 14: 
Requirements 15: 
Requirements 16: 
Requirements 17: 
Requirements 18: 
Requirements 19: 
Requirements 20: 
Requirements 21: 
Requirements 22: 
Requirements 23: 
Requirements 24: 
Requirements 25: 
Requirements 26: 
Requirements 27: 
Requirements 28: 
Requirements 29: 
Requirements 30: 
Requirements 31: 
Requirements 32: 


Requirements 33: 


NFC Digital Protocol 


Implementation of Optional Items eese nnne 5 
Reserved for Future USe............::csscssccossssseccsocssecenseseecncesesnescosescncesoteeneeceseeteesoners 6 
Signal Patterns Poll—Listen — NFC-A A 16 
Modulation Listen Poll — NFC-A .................. esses eere 17 
Signal Patterns Listen Poll — NFC-A .................. sees 18 
De-synchronization Doll Listen — NFC-A ................... eese 19 
De-synchronization Listen Poll — NFC-A ................... eese 19 
Bit Level Coding PollListen — NFC-A ................... eese nenne 20 
Bit Level Coding Listen Poll — NFC-A ................... eese nenne 21 
Frame Format — NFC-A Technology ................... eese nennen 22 
Short Frame Format — NFC-A Technology .................... eese 22 
Standard Frame Format — NFC-A Technology... 23 
Bit Oriented SDD Frame Format. 24 
Bit Oriented SDD Frame Format (Continued) ........................ esee 24 
Data and Payload Format — NFC-A ................. esses eren 25 
INEGCA — Command Seb. eot ipio ett ette d ital dips b pte utes 25 
INECTDI ert Seege 27 
Type 1 Tag Platform Configuration essere ener 27 
Format of SDD_REQ Commande 30 
INE AD EE 32 
Format of SDD RES Response (Complete and Incomplete NFCID1)............ 32 
Format of SDD RES Response (Complete NFCID1 Only) ............................ 32 
Format of SDD RES Response (Incomplete NFCID1 Only).......................... 34 
SEL: RES Respotise...2 eire eech 36 
SLP DNI ———— —Q 37 
EDE STER n RAS nt hse qum tutem Denies 39 
Boca MP ———————— 39 
E EE 39 
age geed A0 
ER AR E 41 
EDI AREACTIVATION ache Sd e EUER Ute eec oS dn edet vest Sead URNA dy 42 
Giüard-Time-— NEG-A s... eise oet ee Yee EX ed 42 
Signal Patterns Pol Listen — NFC-B................... esee rennes 44 
Page xi 


Requirements 34: 
Requirements 35: 
Requirements 36: 
Requirements 37: 
Requirements 38: 
Requirements 39: 
Requirements 40: 
Requirements 41: 
Requirements 42: 
Requirements 43: 
Requirements 44: 
Requirements 45: 
Requirements 46: 
Requirements 47: 
Requirements 48: 
Requirements 49: 
Requirements 50: 
Requirements 51: 
Requirements 52: 
Requirements 53: 
Requirements 54: 
Requirements 55: 
Requirements 56: 
Requirements 57: 
Requirements 58: 
Requirements 59: 
Requirements 60: 
Requirements 61: 
Requirements 62: 
Requirements 63: 
Requirements 64: 
Requirements 65: 
Requirements 66: 


Requirements 67: 


NFC Digital Protocol 


Signal Patterns Listen Poll — NFC-B.................. eese 45 
Synchronization Poll—Listen — NFC-B................... eese 46 
Synchronization Listen Poll — NFC-B................... eese 47 
NFC-B Pattern Group Separation eese enne nennen 48 
NEE Pattern rg EIERE 48 
De-synchronization PollListen — NFC-B ................... eee 49 
De-synchronization Listen Poll — NFC-B ................... eese 49 
Bit Level Coding Poll—Listen — NFC-B ..................... eese 50 
Bit Level Coding Listen Poll — NFC-B ................... eese 50 
Character Format — NFC-B Technology. 51 
Frame Format — NFC-B Technology A 51 
Data and Payload Format — NFC-B .................. eese 52 
tuo ——————— ————— — Hn 53 
Number:of Slots (IN): ette ee 54 
Listen Mode Handling of RFU Values of N AAA 54 
Support for Extended SENSB RES... 55 
INFCTDO in SENSB- RES L4 ep iem bsec ert p oru pentru des 55 
Bit Rates Supported by the NFC Forum Device in Listen Mode..................... 57 
Poll Mode Handling of RFU Value of b4 of Bit. Rate Capability .................. 57 
gj p — P '-————— '———————— 58 
BES rU DU 58 
Poll Mode Handling of RFU Values of SCT... 58 
Protocol Type Supported by the NFC Forum Device in Listen Mode............. 59 
Minimum TRZ ee 60 
Poll Mode Handling of RFU Value of b4 of Protocol Type ........................... 60 
Maximum Value Of EWL,.... ch outer eege 60 
Poll Mode Handling of RFU Value of WI... 60 
EE D nee UD DEN 61 
EE 62 
Poll Mode Handling of RFU Value of SC... 62 
FDI BISTEN MNE TETTE TTD 64 
Bra: Manger sees eebe REENEN eege 65 
i EIN IqU c cR 66 
EDT poti MiN oes eet trier decer EEEE N Ea REE raea e ira 67 

Page xii 


Requirements 68: SFGT — NFC-B oniran leese a eere o nnne ennt nennen trenes 68 
Requirements 69: FOTE nEACTIVATION ----. eren nnne enint n tentes entes tense testen sense 68 
Requirements 70: Guard Time — NFC HB EA 69 
Requirements 71: Creation of Signal Patterns — NFC-F ................. eese 71 
Requirements 72: Reading of Signal Patterns — NC... 71 
Requirements 73: NFC-F Transition Boundaries ........................ esee eerte enne 71 
Requirements 74: Synchronization - NFC-F Seguence. eese 72 
Requirements 75: De-synchronization - NC EE 73 
Requirements 76: Bit Level Coding — NFC. 73 
Requirements 77: Bit Level Decoding — NFC E.A 73 
Requirements 78: NFC-F — Frame Format. 74 
Requirements 79: Data and Payload Format — NFC. 75 
Requirements 80: System Code (SC)... 76 
Requirements 81: Request Code (RC) ........................ eee eeeeeeeiee enne te et netn ne tnnt nennt ento te EENG) 77 
Requirements 82: Time Slot Number (TSN). 78 
Requirements 83: NFCID2 in SENSE RES sees ener nennen nnn nenne 79 
Requirements 847 PAD... aiti ntes eee e EL EO p Pe tenido de re cob eere 79 
Requirements: 85: PADI iis cian ase Hie mao eR Ree 80 
Requirements 86: MRTlIcügck: eiit ette ete tenete eben ee eere eR erre Leak EEE erbe cea orae? 80 
Requirements 87: MRTlIupparE.-. i erre erret e PH Pep Pede LL bep ED Pete Eo i ans 81 
Requirements:88: PAD 2 onreine o eren rite rente tr oo te GENEE ege eege eee eed 81 
Requirements 89: Request Data (RIDE 82 
Requirements 90: FDTgisten,min (except SENSE. REQ)......... eese 84 
Requirements 91: FDTr iisrEN,SENSE REQ-«« eene nennen enne nn ennn enne nninnn entes einen nennen ens 85 
Requirements 92: FDTEPOLEMIN 2 ieri entere ERI pert Eee AE Sesi ire e Een ebbe c ded 86 
Requirements 93: FDT ERE ACTIVATION ENEE 86 
Requirements 94: Guard Time — NC 87 
Requirements 95: General Rules for Half-duplex Transmission Protocol .................................... 88 
Requirements 96: Sequence Format — Type 1 Tag Platform........................ eese 89 
Requirements 97: Bit Level Coding — Type 1 Tag Plattform... 89 
Requirements 98: Frame Format — Type 1 Tag Platform... 90 
Requirements 99: Data and Payload Format — Type 1 Tag, 91 
Requirements 100: RID Command AAA 92 
Requirements 101: RID Response AAA 93 
Requirements 102: Reader-Reader Data Delay CRRDID) nennen 94 


NFC Digital Protocol 


Page xiii 


Requirements 103: 
Requirements 104: 
Requirements 105: 
Requirements 106: 
Requirements 107: 
Requirements 108: 
Requirements 109: 
Requirements 110: 
Requirements 111: 
Requirements 112: 
Requirements 113: 
Requirements 114: 
Requirements 115: 
Requirements 116: 
Requirements 117: 
Requirements 118: 
Requirements 119: 
Requirements 120: 
Requirements 121: 
Requirements 122: 
Requirements 123: 
Requirements 124: 
Requirements 125: 
Requirements 126: 
Requirements 127: 
Requirements 128: 
Requirements 129: 
Requirements 130: 
Requirements 131: 
Requirements 132: 
Requirements 133: 
Requirements 134: 
Requirements 135: 
Requirements 136: 


Requirements 137: 


NFC Digital Protocol 


Frame Delay Times — Type 1 Tag Platform. 95 
Sequence Format — Type 2 Tag Platform. 96 
Bit Level Coding — Type 2 Tag Plattform... 96 
Frame Format — Type 2 Tag Platform. 96 
Frame Format — ACK and NACK Response ...ss.sesssssessseesssressesresseserssessrsseese 97 
Data and Payload Format — Type 2 'Tag, 97 
READ SCIPIO ——— 98 
NACK RESPONSE ie aet ete te ite esta Pete be see E 99 
KR RO 99 
SECTOR SELECT Command Packet 1 Response esses 101 
Passive: ACK Resporise:........... eere Rr hiee teretes rie otn eee Plebe oed dena 101 
Frame Delay Times — Type 2 Tag Plattform. 102 
Sequence Format — Type 3 Tag Platform... 103 
Bit Level Coding — Type 3 Tag Plattform. 103 
Frame Format — Type 3 Tag Plattform... 103 
Data and Payload Format — Type 3 'Tog, sss 103 
AER 105 
ENKE 105 
Sequence Format — Type 4A Tag Platform................. sees 106 
Bit Level Coding — Type 4A Tag Plattform... 106 
Frame Format — Type 4A Tag Plattform... 106 
Data and Payload Format — Type 4A "Tag. 107 
Frame Size for NFC Forum Device in Poll Mode (FSD)............................. 108 
FS Dl vais tec a e e Re rer er aee tre eeu eco Ee ee eR Re e rette es 108 
Listen Mode Handling of RFU Values of FSDIL..................... eese 109 
Support; Of DID: entente teet n T Do o vete en tates 109 
Listen Mode Handling of RFU Value of DI, 109 
Length Byte TL of the ATS ...........eeeeeeseeseeeeee eoori tob Even EEEE ENERE 110 
BS deti deitate aet ederet ete tet Duet aee deese 111 
iron 111 
Poll Mode Handling of RFU Values of FSCI ................. eee 111 
Format Byte TO of the ATS..........ccsscsssssssscsecsscssscssccsscessscsescsensssnsssnsesnnecs 112 
Format Byte TA(1) of the AIS... 113 
Poll Mode Handling of RFU Value of b4 of Interface Byte TA(1) ............. 113 
Interface Byte TB(1) of the ATS... eee eeccessssetseeeeeesecssecsaeceeecsseceseeeseeees 114 


Page xiv 


Requirements 138: 
Requirements 139: 
Requirements 140: 
Requirements 141: 
Requirements 142: 
Requirements 143: 
Requirements 144: 
Requirements 145: 
Requirements 146: 
Requirements 147: 
Requirements 148: 
Requirements 149: 
Requirements 150: 
Requirements 151: 
Requirements 152: 
Requirements 153: 
Requirements 154: 
Requirements 155: 
Requirements 156: 
Requirements 157: 
Requirements 158: 
Requirements 159: 
Requirements 160: 
Requirements 161: 
Requirements 162: 
Requirements 163: 
Requirements 164: 
Requirements 165: 
Requirements 166: 
Requirements 167: 
Requirements 168: 
Requirements 169: 
Requirements 170: 
Requirements 171: 


Requirements 172: 


NFC Digital Protocol 


Poll Mode Handling of RFU Value of PWI.... 114 
Interface Byte TB(1) of the AIS, 114 
Poll Mode Handling of RFU value of SFGI .................... eese 114 
INAD SE 115 
Historical Bytes of the ATS eene ener enne 115 
Frame Timing — Type 4A Tag Dlattom. sese 116 
SFGT — Type 4A Tag Dlattorm eene nennen 117 
Sequence Format — Type 4B Tag Plattform. 118 
Bit Level Coding — Type 4B Tag Platform... 118 
Frame Format — Type 4B Tag Plattform. 118 
Data and Payload Format — Type 4B Tag Plattform... 118 
NFCIDO in ATTRIB Command AAA 119 
Format of Param 1 of the ATTRIB Commande 121 
Listen Mode Handling of RFU Values of Minimum TRO and TR1 ............ 122 
Frame Size for Poll Frame (SIDD)... 122 
e EE 123 
Listen Mode Handling of RFU Values of FSDIL..................... eee 123 
Setting the Bit Rate ier eere neret dee erobern eo 124 
Format of Param 3 of the ATTRIB Commande 124 
Listen Mode Handling of RFU Values of b8 to b4 of Param 3.................... 124 
Format of Param 4 of the ATTRIB Commande 125 
Listen Mode Handling of RFU Value of DI, 125 
Higher. EE E 125 
DID in ATTRIB Responze AE 126 
Higher Layer — Respons Cineo iernare sinio aaeeea ia iene raas iia 126 
Frame Timing — Type 4B Tag Plattform... 127 
Block:Length; 232: 5a: tee Tecan weds eae Gai es 128 
iDDp———————————————— 131 
Power Level Indicator ........................ eee ees esses eene hi e einen thee 131 
Handling of RFU Values of DID Field... 131 
CRG set iei o tauetesteetme ite eate ve tapete eres Ete eR Ie e rper eR 132 
Power Level Indication ...................... eec eee eese eene ener enne tette tnnt trenes 132 
Handling of RFU Values of INF Field of an S(WTX) Response................. 133 
Frame Waiting Time Extension... 134 
Chaining Rules... rete iere other eet ee Re Dye eee e ee ve EES 135 

Page xv 


Requirements 173: 
Requirements 174: 
Requirements 175: 
Requirements 176: 
Requirements 177: 
Requirements 178: 
Requirements 179: 
Requirements 180: 
Requirements 181: 
Requirements 182: 
Requirements 183: 
Requirements 184: 
Requirements 185: 
Requirements 186: 
Requirements 187: 
Requirements 188: 
Requirements 189: 
Requirements 190: 
Requirements 191: 
Requirements 192: 
Requirements 193: 
Requirements 194: 
Requirements 195: 
Requirements 196: 
Requirements 197: 
Requirements 198: 
Requirements 199: 
Requirements 200: 
Requirements 201: 
Requirements 202: 
Requirements 203: 
Requirements 204: 
Requirements 205: 
Requirements 206: 


Requirements 207: 


NFC Digital Protocol 


Block Sizes during Chaintng. 135 
East BLOCK. DS 135 
Block Numbering Rules AA 136 
General Block Handling Rules........................ esee 136 
Block Handling Rules for the Reader/Writer ....................... sees 137 
Block Handling Rules for the Card Emulator eese 138 
Exception Processing — Card Emulator..................... seen 138 
Exception Processing — Reader/Writer ................. eese 139 
Deactivation RUES S eeren crit o rhet eet eee cin du ede tovetuSontoteaeees 141 
Error Handling for Deactivation ..............ccccesscessceeseeereeeeeeeeeeeeeceecneceseeeseees 141 
Timing — Type 4A and Type 4B Tag Half-duplex Protocol ........................ 142 
Sequence Format — NFC-DEP Protocol.................. eese 143 
Bit Level Coding — NFC-DEP Protocol ..................... eese 143 
Frame Format — NFC-DEP Protocol.................... essent 144 
Data and Payload Format — NFC-DEP Protocol........................ eese 145 
Attribute Request Length. 146 
NEGIDO3; FORMAL «iere ee reete e nere ree eit o oe Potter erre gs 146 
Initiator Device Identification Number OD... 147 
BSrand BR; Goding...... eee eoe tee titre tete 147 
PP:Eormat:a... 2: enn EHI peni 148 
ER ——————————————— 148 
NEGID23g el TG 149 
Target Device Identification Number (DID) ........................ eee 149 
BS, and BR, Format. 150 
RER e EE 151 
Initiator Handling of RFU Value of WI. 151 
RE OR inno retten mam ete emm 152 
DD ———— ——————————— 152 
DID — PSL. REQ Commande 152 
EE 154 
DID: PSL- RES RESPONSO ee rete tere tne eee erre E rene rp 154 
DID - DEP. REQ Commande 155 
DID —DEP RES Respons coneccion aE e never pee ene reis 156 
Response Timeout Extension. 159 
DID- DSK :REQ Gommand.......... terret eere tere Gaceecoossesvese erede 160 

Page xvi 


Requirements 208: DID — DSL. RES Responsze ette ennnee enne nnne ettet enne 161 


Requirements 209: RLS_REQ Commande 162 
Requirements 210: RLS. RES Response 162 
Requirements 211: Frame Timing — NFC-DEP Protocol..................... eese 163 
Requirements 212: Response Waiting Time E 164 
Requirements 213: Chaining Rule... 165 
Requirements 214: Block Sizes during Chatming. ener 165 
Requirements 215: PDU Numbering Rules esee nennen eene tenter tnnt ennt 166 
Requirements 216: General PDU Handling Rules AA 167 
Requirements 217: PDU Handling Rules for the Initiator .....................seseeeeeeeeeenrenn 167 
Requirements 218: PDU Handling Rules for the "Targert. AA 167 
Requirements 219: Exception Processing — Target...................... eese enne enne 168 
Requirements 220: Exception Processing — Initiator .....................eeeeeeeeceeeeeeeeeene nennen 169 
Requirements: 22 17 Values: E ——— ——Ó 170 


NFC Digital Protocol Page xvii 


Introduction 


1 Introduction 


1.1 Scope 


The scope of this document covers the digital interface and the half-duplex transmission protocol 
of the NFC Forum Device in its four roles (Initiator, Target, Reader/Writer, and Card Emulator). 


This includes the modulation schemes, bit level coding, bit rates, frame formats, protocols, and 
command sets. 


Within this scope, the Active Communication mode is not described in the current version of this 
document. 


1.2 Audience 


This document is intended for use by manufacturers wanting to implement an NFC Forum 
Device. 


1.3 Applicable Documents or References 


The following documents contain provisions that are referenced in this specification. The latest 
version including all published amendments applies unless a publication date is explicitly stated. 


[ACTIVITY] NFC Activity Specification, 
Version 1.0, 

September 2010, 

NFC Forum 


[ANALOG] NFC Analog, 
Latest version, 
NFC Forum 


[EMV CLESS] EMV Contactless Communication Protocol Specification, 
Version 2.0 
July 2008 
EMVCo 


[ISO/IEC 13239] ISO/IEC 13239, 
Information technology — Telecommunications and information 
exchange between systems — High-level data link control (HDLC) 
procedures, 
2002, 
ISO/IEC 
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[ISO/IEC 14443] 


[ISO/TEC 18092] 


[JIS. X 6319-4] 


[RFC2119] 


[T1TOP] 


[T2TOP] 
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Identification cards — Contactless integrated circuit cards — Proximity 
cards 


Includes: 


e [ISO/IEC 14443-1:2008], Identification cards — Contactless 
integrated circuit cards — Proximity cards — Part 1: Physical 
characteristics 


e [ISO/IEC 14443-2:2010], Identification cards — Contactless 
integrated circuit cards — Proximity cards — Part 2: Radio frequency 
power and signal balance 


e [ISO/IEC 14443-3:2001], Identification cards — Contactless 
integrated circuit cards — Proximity cards — Part 3: Initialization and 
anticollision 


e [ISO/IEC 14443-3:2001/Amd.1], Identification cards -- Contactless 
integrated circuit(s) cards -- Proximity cards -- Part 3: Initialization 
and Anti-collision, 1 February 2001 with Amendment 1: Bit rates of 
fc/64, fc/32 and fc/16, 15 June 2005; Amendment 3: Handling of 
reserved fields and values, 22 March 2006; and Corrigendum 1: 
Amendment 1 - Corrigendum, 29 August 2006 


e [ISO/IEC 14443-4:2008], Identification cards — Contactless 
integrated circuit cards — Proximity cards — Part 4: Transmission 
protocol 


ISO/IEC 


ISO/IEC 18092: 

Information technology — Telecommunications and information 
exchange between systems — Near Field Communication — Interface and 
Protocol (NFCIP-1) 

2004 

ISO/IEC 


JIS X 6319-4 

Specification of implementation for integrated circuit(s) cards — 
Part 4: High speed proximity cards 

2005 

JIS 


Key words for use in RFCs to Indicate Requirement Levels, RFC 2119, 
S. Bradner, 

March 1997 

Internet Engineering Task Force 


Type 1 Tag Operation Specification 
Version 1.0, 

July 2007 

NFC Forum 


Type 2 Tag Operation, 
Version 1.0, 


July 2007 
NFC Forum 
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[T3TOP] Type 3 Tag Operation, 
Version 1.0, 
August 2007 
NFC Forum 


[TATOP] Type 4 Tag Operation, 
Version 2.0, 
September 2010 
NFC Forum 


1.4 Administration 


The NFC Digital Protocol is an open specification supported by the Near Field Communication 
Forum, Inc., located at: 


401 Edgewater Place, Suite 600 
Wakefield, MA, 01880 


Tel.: +1 781-876-6216 
Fax: *1 781-610-9864 


http://www.nfc-forum.org/ 


The NFC Devices Technical Working Group maintains this specification. 


1.5 Name and Logo Usage 


The Near Field Communication Forum's policy regarding the use of the trademarks NFC Forum 
and the NFC Forum logo is as follows: 


e Any company MAY claim compatibility with NFC Forum specifications, whether a member 
of the NFC Forum or not. 


e Permission to use the NFC Forum logos is automatically granted to designated members only 
as stipulated on the most recent Membership Privileges document, during the period of time 
for which their membership dues are paid. 


e Member's distributors and sales representatives MAY use the NFC Forum logo in promoting 
member's products sold under the name of the member. 


e The logo SHALL be printed in black or in color as illustrated on the Logo Page that is 
available from the NFC Forum at the address above. The aspect ratio of the logo SHALL be 
maintained, but the size MAY be varied. Nothing MAY be added to or deleted from the 
logos. 


e Since the NFC Forum name is a trademark of the Near Field Communication Forum, the 
following statement SHALL be included in all published literature and advertising material in 
which the name or logo appears: 


NFC Forum and the NFC Forum logo are trademarks of the Near Field Communication 
Forum. 
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1.6 Intellectual Property 


The NFC Digital Protocol conforms to the Intellectual Property guidelines specified in the NFC 
Forum's Intellectual Property Rights Policy, as outlined in the NFC Forum Rules of Procedure. 


1.7 Acknowledgements 
Extracts are derived from [ISO/IEC 14443] and [ISO/IEC 18092]. 


British Standards can be obtained in PDF or hardcopy formats from the BSI online shop at 
www.bsigroup.com/Shop or by contacting BSI Customer Services for hardcopies only at 
+44 (0)20 8996 9001, email: cservices@bsigroup.com. 


1.8 Special Word Usage 
The following words have a special meaning in this specification: 
e MUST and MAY 
The key words MUST and MAY are to be interpreted as described in [RFC2119]. 
e HAS TO and HAVE TO 


The key words HAS TO and HAVE TO indicate functionality that is mandatory yet outside 
of the scope of this specification. Therefore, statements using HAS TO and HAVE TO are 
not normative. 


e MUST RAISE THE «error» PROTOCOL EXCEPTION 


Certain events are identified in the digital protocol that affects upper layer protocols that are 
not specified in this specification. For the purposes of describing these dependencies between 
independent specifications, those events and conditions are described through the raising of a 
protocol exception indicated by the key words: MUST RAISE THE «error» PROTOCOL 
EXCEPTION. 

This does not imply particular implementation requirements or any specific implementation 
architecture. It is not anticipated that these events will be externally observable or 
distinguishable and therefore they are not suitable for conformance testing. 


1.9 Requirement Numbering 


Requirements in this document are uniquely numbered with the number appearing next to each 
requirement. Requirements can include informative statements in the italic font. For example: 


Table 1: Sample Requirement 


1.9.1.1 A car MUST have four wheels. 
A car MAY have alloy wheels. 


A requirement can have different numbers in different versions of the specifications. Hence, all 
references to a requirement must include the version of the document as well as the requirement's 
number. 
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1.10 Implementation of Optional Items 


This specification contains items declared as optional for an implementation. However, if 
optional items are implemented, they have to be implemented as specified in this specification. 


Requirements 1: Implementation of Optional Items 


Poll and Listen Mode 


1.10.1.1 The NFC Forum Device implementing an item declared as optional MUST 
implement it as specified in this specification. 


NOTE For example, NFC-B in Listen Mode is declared optional. This indicates that an 
implementation can choose to not implement it, but if NFC-B technology in Listen 
Mode is implemented, it has to be implemented as specified in this specification. 


1.11  Notational Conventions 


1.11.1 Notations 


The notations as shown in Table 2 apply in this document: 


Table 2: Notational Conventions 


Notation Description 


XYh Hexadecimal notation. 
Values expressed in hexadecimal form are followed by a lower case “h”. 
For example, 27509 decimal is expressed in hexadecimal as 6B75h. 
XYb Binary notation. 
Values expressed in binary form are followed by a lower case “b”. 
For example, 82h hexadecimal is expressed in binary as 10000010b. 


Optional part. 


XX More than one value possible. 


STATE States are written in COURIER FONT to distinguish them from the text. 


1.11.2 Value of Parameters 


Throughout the document, symbols are used to identify the values of parameters. The actual 
values of the parameters are listed in Appendix A. Symbols referenced in Appendix A are written 
in Arial bold to distinguish them in the text. 
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Requirements 2: Reserved for Future Use 


Poll and Listen Mode 


1.11.2.1 The NFC Forum Device sending bytes or bits defined as RFU MUST set these bytes 
or bits to the value indicated, or to zero if no value is given. 


1.11.2.2 The NFC Forum Device receiving bytes or bits defined as RFU MUST disregard 
these bytes or bits and MUST keep the same interpretation of any other field of the 
whole response, unless explicitly stated otherwise. 


The NFC Forum Device sending bytes or bits defined as Any Value MAY set these bytes or bits to 


any specific value. 


How to process bytes or bits received that are defined as Any Value is out of scope of this 
specification, where not explicitly stated otherwise. 


1.12 Abbreviations 


Abbreviation Description 

ASK Amplitude Shift Keying 

ATN Attention 

BCC UID CLn check byte for NFC-A 

bd Bit Duration 

CLn Cascade Level n (1 E n € 3) 

CRC Cyclic Redundancy Check, a checksum appended within the data 
segment before transmission, and verified afterwards by the 
recipient to detect Transmission Errors 

CRC A CRC error detection code for NFC-A 

CRC B CRC error detection code for NFC-B 

CRC F CRC error detection code for NFC-F 

DID Device Identification Number 

DuyisrEN POLL Divisor for communication direction Listen Poll 

DPoLL>LISTEN Divisor for communication direction Poll—Listen 

EoD End of Data 

EoF End of Frame 

EoS End of Sequence 

fc Carrier Frequency 

FWI Frame Waiting time Integer 

FWT Frame Waiting Time 

IEC International Electrotechnical Commission 

ISO International Organization for Standardization 
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Abbreviation 

JIS Japanese Industrial Standard 

LSB Least Significant Byte 

Isb Least Significant Bit 

Max 

MBL Maximum Buffer Length 

MBLI Maximum Buffer Length Index 

Min 

MRT Maximum Response Time 

MRTI Maximum Response Time Information 

MSB Most Significant Byte 

msb Most Significant Bit 

n.a Not Applicable 

NAD Node Addressing 

NDEF NFC Data Exchange Format 

NFC Near Field Communication 

NFC-A Near Field Communication — Type A Technology 

NFC-B Near Field Communication — Type B Technology 

NFC-F Near Field Communication — Type F Technology 

NFCIDO NFC-B identifier of the NFC Forum Device. 
NFCIDO is always 4 bytes long. 

NFCID1 NFC-A identifier of the NFC Forum Device in the Passive 
Communication mode. 
NFCID1 can be 4, 7, or 10 bytes long (simple, double, or triple 

NFCID1 CLn Contains the portion of the NFCID1 relative to the Cascade 
NFCID1 CLn is always 4 bytes long. 

NFCID2 NFC-F identifier of the NFC Forum Device in the Passive 
Communication mode. NFCID2 is always 8 bytes long. 

NFCID3 NFCIP-1 identifier of the NFC Forum Device. 
NFCID3 is always 10 bytes long. 

NFCIP-1 Near Field Communication Interface and Protocol as specified in 
[ISO/IEC 18092]. 

NRZ-L Non-Return to Zero (L for Level) 

OOK On-Off Keying 
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Abbreviation Description 

PDU Protocol Data Unit 

RF Radio Frequency (RF field = magnetic field) 
RFU Reserved for Future Use 

RRDD Reader-Reader Data Delay 

RTOX Response Timeout Extension 

RWT Response Waiting Time 

SDD Single Device Detection 

SFGI Start-up Frame Guard time Integer 
SFGT Start-up Frame Guard Time 

SoD Start of Data 

SoF Start of Frame 

SoS Start of Sequence 

WT Waiting Time, parameter to code RWT 


1.13 Glossary 


1.13.1 Device and Communication 
Active Communication 


A communication mode in which each device generates its own RF field to send a 
message to another device. 


Command 


An instruction from one device to another device in order to move the other device 
through a state machine. 


Connectionless Transport 

An unacknowledged data transmission service with minimal protocol complexity. 
Listen Frame 

A frame sent by an NFC Forum Device in Listen Mode. 
NFC Forum Device 


A device that supports the following Modus Operandi: Initiator, Target, and 
Reader/Writer. It may also support Card Emulator. 


NFC Tag 
A contactless tag or (smart) card supporting NDEF over Passive Communication. 
Operating Field 


The magnetic field created by an NFC Forum Device in Poll Mode within the Operating 
Volume. 
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Operating Volume 


The three-dimensional space, as defined by the NFC Forum, in which an NFC Forum 
Device in Poll Mode can communicate with an NFC Forum Device in Listen Mode. 


Passive Communication 


A communication mode in which one device generates an RF field and sends Commands 
to a second device. To respond, this second device uses load modulation (i.e., it does not 
generate an RF field but it draws more or less power from the RF field). 


Poll Command 
A Command to query an NFC Forum Device in Listen Mode or an NFC Forum Tag: 
e ALL REQ or SENS REQ Command for NFC-A 
e ALLB REQ or SENSB REQ Command for NFC-B 
e SENSF REQ Command for NFC-F 
Poll Frame 
A frame sent by an NFC Forum Device in Poll Mode. 
Response 


Information sent from one device to another device upon receipt of a Command. The 
information received by the other device should allow this other device to continue the 
data exchange. 


Technology 


A group of transmission parameters defined by the NFC standard that make a complete 
communication protocol. A non-exhaustive list of transmission parameters is: RF carrier, 
communication mode, bit rate, modulation scheme, bit level coding, frame format, 
protocol, and Command set. NFC defines three groups and therefore three Technologies: 
NFC-A, NFC-B, and NFC-F. The three Technologies use the same RF carrier (13.56 
MHz). Each Technology uses its own modulation scheme, bit level coding and frame 
format, but may have the same protocol and Command set. 


Technology Subset 


A legacy platform supporting a subset of a Technology. A Technology Subset supports at 
least the Poll Command of the Technology. The four Technology Subsets described in 
this specification are: 


e Type 1 Tag platform, which uses a particular subset of NFC-A, excluding anti- 
collision. 


e Type 2 Tag platform, which uses a particular subset of NFC-A, including anti- 
collision. 


e Type 3 Tag platform, which uses a particular subset of NFC-F, including anti- 
collision. 


e Type 4 Tag platform, which uses a particular subset of NFC-A or NFC-B, including 
anti-collision. 
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1.13.2 Protocol and Mode 
Activity 


A process within an NFC Forum Device with well defined pre-conditions and post- 
conditions, as defined in [ACTIVITY]. An Activity can only start when its pre-conditions 
are fulfilled. When an Activity ends, its post-conditions are fulfilled. 


Card Emulator 


A role of an NFC Forum Device, reached when an NFC Forum Device in Listen Mode 
has gone through a number of Activities and in which the NFC Forum Device behaves as 
one of the Technology Subsets. 


Initiator 


A role of an NFC Forum Device reached when an NFC Forum Device in Poll Mode has 
gone through a number of Activities; in this mode the NFC Forum Device communicates 
using the NFC-DEP Protocol. 


ISO-DEP Protocol 


Half-duplex block transmission protocol defined in Section 13 and based on 
[ISO/TEC 14443] and [EMV CLESS]. 


Listen Mode 


Initial mode of an NFC Forum Device when it does not generate a carrier; in this mode 
the NFC Forum Device listens for the RF field of another device. 


NFC-DEP Protocol 


Half-duplex block transmission protocol defined in Section 14 and based on 
[ISO/IEC 18092]. 


Poll Mode 


Initial mode of an NFC Forum Device when it generates a carrier and probes (“polls”) for 
other devices. 


Reader/Writer 


Role of an NFC Forum Device reached when an NFC Forum Device in Poll Mode has 
gone through a number of Activities. In this mode, the NFC Forum Device behaves like a 
legacy contactless reader and uses Commands from one of the Technology Subsets. 


Target 


Role of an NFC Forum Device, reached when the NFC Forum Device has gone through a 
number of Activities in which the NFC Forum Device communicates using the NFC-DEP 
Protocol. 


1.13.3 Errors 
Protocol Error 


A Semantic Error or Syntax Error. 
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Semantic Error 
A Correct Frame with no Syntax Error is received when it is not expected.’ 
Syntax Error 


A Correct Frame is received with an invalid content. In this case, the coding of the 
Command or the block within the frame is not consistent with this specification. 


Timeout Error 
No Response has been received within the Response Waiting Time (RWT). 
Transmission Error 


An incorrect frame is received. In this case, the signal modulation, the bit coding, the 
frame format, the timing, or the checksum is not consistent with this specification. 


Correct Frame 

A frame without Transmission Error. 
Valid Block, Valid PDU 

A block or PDU without Protocol Error within a Correct Frame. 
Valid Command, Valid Response 


A Command or Response without Protocol Error within a Correct Frame. 


t A semantic error does not occur in this document. It is only included for consistency. 
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2 Overview 


This specification covers the digital protocol of NFC Forum Device communication in Passive 
Mode. 


An NFC Forum device exchanges information, referred to as “payload” in this document, by 
transmitting data packages. A data package optionally begins with a Start of Data (SoD) 
consisting of a start byte and/or a length byte, followed by the payload, and optionally ends with 
an End of Data (EoD). If present, the EoD consists of a two-byte checksum. 


Data packages, which are digital information composed of the values Logic “0” and Logic “1”, 
are embedded in frames. These frames are optionally delimited by a Start of Frame (SoF) and an 
End of Frame (EoF). SoF, EoF, "0", and "1" are coded digitally. This means that these elements 
are coded by using combinations of only two different values (e.g., a high/low signal level or a 
0°/180°signal phase). 


Frames are embedded in sequences to synchronize and calibrate the sending and receiving 
devices and to trigger and stop the signal-decoding process in the receiving device. A sequence 
contains a frame with a particular leading signal pattern called Start of Sequence (SoS) and a 
particular closing signal pattern called End of Sequence (EoS). 


Table 3 summarizes the structure of this document. The left column contains the different 
Activities. The upper row of the right column shows that the behavior of the NFC Forum Device 
during the Mode Switch Activity, the Collision Detection Activity, and the Collision Resolution 
Activity depends on its Technology only. The lower row of the right column illustrates that the 
behavior of the NFC Forum Device during the Device Activation Activity, the Data Exchange 
Activity, and the Device Deactivation Activity also depends on its Technology Subset. 


NFC Digital Protocol Page 12 


Overview 


Table 3: Activities versus Technology / Device Platform 


Activity Technology / Device Platform 
Listen, RF 
Collision 
By Olan. NEGA MECH  |NFC-F 
Technology | 
Detection, Section 4 Section 5 | Section 6 
Collision 
Resolution 
Device Type 1 Type 2 Type 4A |Type4B | Type 3 Tag 
Activation Tag Tag Tag Tag Platform 

Platform |Platform | Platform | Platform | section 10 

Section8 |Section9 |Section | Section 12 

11 
Data NFC-DEP Type 1, 2, See 
Exchange Protocol |Type1,2,and3Tag |ISO-DEP Protocol and 3 Tag 
Section 14 | Half-duplex Protocol | section 13 Half-duplex 
Section 7 Protocols | Section 14 

Device 
Deactivation Section 7 
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3 Bit Duration 


The bit duration indicates the timing of a digital signal. For this document, the bit duration (bd) is 
the time it takes to transmit one unit of information. 


For communication direction Poll—Listen, the bit duration is defined as follows: 
1 bd = 128 / (fc x Deor, SuisreN) 
For communication direction Listen Poll, the bit duration is defined as follows: 


1 bd = 128 / (fc x Dusten-sPoLt) 


where fc is the constant carrier frequency generated by the NFC Forum Device in Poll Mode, and 
the integers Dpottststen and Di jsrEN S Por are divisors that have the value 1, 2, or 4. 


For NFC-A and NFC-B communication initiation, the value of Dpoii ,usreN and DuistenspoLL is 
equal to 1. 


For NFC-F communication initiation, the value of Dpottsusten and DyisreN s pour is equal to 2 or 
4, depending on the configuration. 


The communication initiation covers the Mode Switch Activity, Collision Detection Activity, 
Collision Resolution Activity, and Device Activation Activity (see [ACTIVITY ]). 
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4 NFC-A Technology 


This section specifies the NFC-A Technology-related features of the NFC Forum Device. 
Information defined elsewhere is included for readability reasons. 


If not explicitly stated otherwise, [ISO/IEC 18092] is the normative reference for this section. 
Deviations from and restrictions of [ISO/TEC. 18092] are indicated within the text on the topics 
for which deviations and restrictions apply. 

4.1 Sequence Format 


This section describes the sequence format for NFC-A Technology. 


4.1.1  Poll5Listen Modulation 


In Poll Mode, the analog signal is modulated using Modified Miller coding with ASK 10096 
modulation, as illustrated in Figure 1. 


V pattern X pattern Y pattern Z pattern X pattern X 
100 96 


\ | M 
5 96 OTT cc LLL cc 
e E pe T 


ATMA 
| | 
- 100 % 


DUO cc MUI rc 
WEE 


1 bd 


Figure 1: Modified Miller Coding with ASK 10096 


The modulation principle of ASK 10096 of the Operating Field is used to create V2. Refer to 
[ANALOG] for the definition of V;. 


Modified Miller coding uses these V; to define three particular patterns: X, Y, and Z. 
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4.1.1.1 


NOTE 


NFC-A Technology 


Requirements 3: Signal Patterns Poll Listen - NFC-A 


The NFC Forum Device MUST 
build signal patterns X, Y, and Z, 
as follows: 


Pattern X: at the beginning of 
the bit duration, no modulation 
MUST occur for a time of half 
the bit duration. After a time of 
half the bit duration, a V2 
MUST occur. 


Pattern Y: for the full bit 
duration, no modulation 
MUST occur. 


Pattern Z: at the beginning of 
the bit duration, a Vj MUST 
occur. For the rest of the bit 
duration, no modulation 
MUST occur. 
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Listen Mode 


4.1.1.2 


The NFC Forum Device MUST 
read signal patterns X, Y, and Z, 
as follows: 


If the NFC Forum Device 
detects no modulation for a 
time of half the bit duration 
and a Vs after a time of half 
the bit duration, the NFC 
Forum Device MUST read 
this as pattern X. 


If the NFC Forum Device 
detects a V2 at the beginning 
of the bit duration and no 
modulation for the rest of the 
bit duration, the NFC Forum 
Device MUST read this as 
pattern Z. 


If the NFC Forum Device 
does not detect any 
modulation during the entire 
bit period, the NFC Forum 
Device MUST read this as 
pattern Y. 


All other patterns MUST be 
treated as invalid patterns. 


The term “Pulse” as used in [ISO/IEC 18092] is referred to as V2 in this document. 
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4.1.2  ListenPoll Modulation 


In Listen Mode, the analog signal is modulated using Manchester coding with OOK subcarrier 
modulation (see Figure 2). 


Loaded State 


pattern D pattern E pattern D pattern D pattern D 


10096 


-100% s ] 


1 bd 


Figure 2: Manchester Coding with OOK 


Manchester coding uses OOK subcarrier modulation to define three particular patterns: E, D, 
and F. 


Requirements 4: Modulation Listen—Poll - NFC-A 
Listen Mode 


4.1.2.1 The NFC Forum Device MUST modulate the carrier with the subcarrier such that 
the bit period starts with the loaded state of the subcarrier (see Figure 2). 
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4.1.2.2 


NFC-A Technology 


Requirements 5: Signal Patterns Listen Poll - NFC-A 


The NFC Forum Device MUST 
read the patterns D, E, and F as 
follows: 


e Ifthe carrier is modulated 
with the subcarrier for the 
first half of the bit duration 
and is not modulated for the 
second half of the bit 
duration, the NFC Forum 
Device MUST read that as 
pattern D. 


e Ifthe carrier is not 
modulated with the 
subcarrier for the first half of 
the bit duration and is 
modulated for the second 
half of the bit duration, the 
NFC Forum Device MUST 
read that as pattern E. 


e Ifthe carrier is not 
modulated with the 
subcarrier during one full bit 
period, the NFC Forum 
Device MUST read this as 
pattern F. 


e All other patterns MUST be 
treated as invalid patterns. 


Listen Mode 


4.1.2.3 


The NFC Forum Device MUST 


build the patterns D, E, and F as 
follows: 


Pattern D: the carrier MUST be 
modulated with the subcarrier 
for the first half of the bit 
duration and MUST not be 
modulated for the remaining 
part of the bit duration. 


Pattern E: the carrier MUST not 
be modulated with the 
subcarrier for the first half of 
the bit duration and MUST be 
modulated for the second half 
of the bit duration. 


Pattern F: the carrier is not 
modulated with the subcarrier 
for one bit duration. 


4.1.3 Synchronization 


NFC-A Technology does not require signal synchronization and therefore, SoS is not present. 
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4.1.4 De-synchronization 


The EoS indicates the end of a sequence. 


Requirements 6: De-synchronization PollListen - NFC-A 


Poll Mode Listen Mode 

4.1.4.1 The NFC Forum Device MUST 4.1.4.2 The NFC Forum Device MUST 
code EoS as follows: decode EoS as follows: 
e  EoS: pattern Y. e If the NFC Forum Device 


detects pattern Y after pattern 
Y, then it MUST decode the 
last pattern Y as EoS. 


e If the NFC Forum Device 
detects pattern Y after pattern 
Z, then it MUST decode 
pattern Y as EoS. 


Requirements 7: De-synchronization Listen—>Poll - NFC-A 


Poll Mode Listen Mode 

4.1.4.3 The NFC Forum Device MUST 4.1.4.4 The NFC Forum Device MUST 
decode EoS as follows: code EoS as follows: 
e If the NFC Forum Device e EoS: pattern F 


detects pattern F, then it MUST 
decode this as EoS. 


4.2 Bit Level Coding 


4.2.1  PolloListen Coding Scheme 


The patterns X, Y, and Z are used to code the digital alphabet Logic “0” and Logic “1”. 
Logic *0"s and Logic “1”s are the components of frames. 
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Requirements 8: Bit Level Coding Poll Listen - NFC-A 


Poll Mode 


4.2.1.1 The NFC Forum Device MUST code 
Logic “0” and Logic “1” as follows: 


e Logic “1”: pattern X 

e Logic “0”: pattern Y 

with the following exceptions: 

e Pattern Z MUST be used to code 
the first Logic “0” (SoF). 


e If there are two or more 
contiguous Logic “0”s, pattern Z 
MUST be used from the second 
Logic “0” on. 
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Listen Mode 


4.2.1.2 


The NFC Forum Device MUST 
decode Logic “0” and Logic “1” 
as follows: 


The first pattern Z MUST be 
decoded as Logic “0”. 

If the NFC Forum Device 
detects pattern X, then it 
MUST decode this as 

Logic “1”. 

If the NFC Forum Device 
detects pattern Y after 
pattern X, then it MUST 
decode pattern Y as 

Logic “0”. 

If the NFC Forum Device 
detects pattern Z after pattern 
Y, then it MUST decode 
pattern Z as Logic “0”. 


If the NFC Forum Device 
detects pattern Z after pattern 
Z, then it MUST decode the 
last pattern Z as Logic “0”. 


Invalid patterns MAY be treated as 
Transmission Errors, or the device MAY use 
implementation-dependent methods to 
decode an invalid pattern into a Logic ‘0” or 


Logic “1”. 
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4.2.2 Listen Poll Coding Scheme 


The patterns E and D are used to code the digital alphabet Logic “0” and Logic “1”. Logic *0"s 
and Logic *1"s, referred to as data bits in the following, are the components of frames. 


Requirements 9: Bit Level Coding Listen—Poll - NFC-A 


Poll Mode Listen Mode 
4.2.2.1 The NFC Forum Device MUST 4.2.2.2 The NFC Forum Device MUST 
decode Logic “0” and Logic “1” as code Logic “0” and Logic “1” as 
follows: follows: 
e Ifthe NFC Forum Device detects e Logic “1”: pattern D 
pattern D, then it MUST decode e Logic “0”: pattern E 


this as Logic “1”. 
e Ifthe NFC Forum Device detects 

pattern E, then it MUST decode 

this as Logic “0”. 
Invalid patterns MAY be treated as Transmission 
Errors, or the device MAY use implementation- 
dependent methods to decode an invalid pattern 
into a Logic *0" or Logic *1". 


4.3 Frame Format 


Data bits, when transmitted between NFC Forum Devices, are grouped within frames. The format 
of a frame is different for each Technology. NFC-A Technology groups the data bits together in a 
frame by adding an SoF and an EoF. A parity bit (P) is added at the end of each 8 data bits. 


This section defines the frames of NFC Forum Devices configured for NFC-A Technology. NFC- 
A Technology uses three types of frames: short frame, standard frame, and bit-oriented SDD 
frame. The short frame is used to initiate communication (wake-up). The standard frame is used 
for data exchange. The bit-oriented SDD frame is used for collision resolution. 


NOTE Definitions in Section 4.3 overrule deviating definitions in [ISO/IEC 18092]. 
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Requirements 10: Frame Format - NFC-A Technology 
Poll and Listen Mode 


4.3.1.1 A frame MUST start with SoF. 
For Poll—Listen communication, the SoF MUST be a Logic “0”. 
For Listen Poll communication, the SoF MUST be a Logic “1”. 


4.3.1.2 A frame MUST end with EoF. 
For Poll Listen communication, EoF MUST be a Logic “0”. 


For Listen Poll communication, EoF MUST be a Pattern F (see Requirement 
4.1.2.3). 


4.3.2 Short Frame 
A short frame is used to initiate communication and consists of the following (see Figure 3): 
e SoF 
e Upto 7 data bits transmitted lsb first 
e EoF 
No parity is added. 
| Isb msb 
SoF | bl b2 b3 b4 b5 b6 b7 EoF 


Figure 3: Short Frame 
Requirements 11: Short Frame Format - NFC-A Technology 
Poll and Listen Mode 


4.3.2.1 Following the SoF and preceding the EoF, the short frame MUST contain less than 
8 data bits. 


4.3.8 Standard Frame 

Standard frames are used for data exchange and consist of the following (see Figure 4): 
e SoF 

e n* (8 data bits + odd parity bit), with n > 1 


e  EoF (Poll—Listen communication only) 


n * (8 data bits odd parity bit) 


SoF FELFERRELERLL 'EREEFEER 
1* byte 2™ byte n" byte 


parity parity parity 


Figure 4: Standard Frame (Poll Listen Communication) 
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Requirements 12: Standard Frame Format - NFC-A Technology 
Poll and Listen Mode 


4.3.3.1 Each 8 data bits in a standard frame MUST be followed by an odd parity bit. The 
parity bit P MUST be set such that the number of Logic *1"s is odd in the set 
consisting of b1 to b8 and P. 


4.3.4 Bit Oriented SDD Frame 


Bit oriented SDD frames are used for collision resolution and result from a standard frame with a 
length of 7 bytes that is split into two parts. The split can occur after any data bit. Figure 5 shows 
an example with the split after the first bit of the second byte. 


Standard Frame (with 7 bytes length) 


7 * (8 data bits + odd parity bit) 


<+— 7" byte —> 


vBRELERBEREPRS3RMEEEREEREEERKFE 
'1* byte '2™ byte (b2 - b8) 7" byte 


2" byte (b1) 


Bit Oriented SDD Frame Bit Oriented SDD Frame 
Part 1 Part 2 


Figure 5: Bit Oriented SDD Frame (with Split after the First Bit of the Second Byte) 


Bit oriented SDD frames are characterized as follows: 
e Bit oriented SDD frames have a SoF and an EoF. 
e Part1 of a bit oriented SDD frame is always sent by an NFC Forum Device in Poll Mode. 


e Part2 of a bit oriented SDD frame is always sent by an NFC Forum Device in Listen Mode in 
response to part 1. 


e The sum of data bits of part 1 and part 2 is 56 (7 bytes with 8 data bits each). 
e The minimum length of part 1 is set to 16 data bits. 
e The maximun length of part 1 is set to 55 data bits. 


e As a result, the minimum length of part 2 are 8 data bits, the maximum length of part 2 is 40 
data bits. 


e If the split occurs after the eighth data bit of a byte, then the related parity bit is added after 
the last data bit of part 1. 


e If the split occurs at another position within a byte, then no parity bit is added after the last 
data bit of part 1, and the first parity bit of part 2 is undefined. 


NOTE If the split occurs after the eighth (i.e., the last) data bit of a byte, then part 1 and part 
2 of the bit oriented SDD frame have the same format as standard frames. 
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Requirements 13: Bit Oriented SDD Frame Format 
Poll and Listen Mode 


4.3.4.1 Each 8 data bits in a bit oriented SDD frame MUST be followed by an odd 
parity bit. The parity bit P MUST be set such that the number of Logic “1”s is 
odd in the set consisting of b1 to b8 and P. 


Requirements 14: Bit Oriented SDD Frame Format (Continued) 


Poll Mode Listen Mode 

4.3.4.2 The minimum length of part 1 4.3.4.3 The sum of data bits of part 1 
MUST be 16 data bits. The and part 2 MUST be 56, as 
maximum length of part 1 illustrated in Figure 5. 


MUST be 55 data bits. 


4.3.4.4 If the split occurs after the eighth 4.3.4.5 If the split occurs at a position 


data bit of a byte, then the within a byte (i.e., the split does 
related parity bit MUST be not occur after the eighth data 
added after the last data bit of bit), then the first parity bit of 
part 1. part 2 is undefined. 
The first parity bit of part 2 MAY be set to 
Any Value. 


4.4 Data and Payload Format 


Data transmitted in an NFC-A standard frame (i.e., the bytes between SoF and EoF), have the 
following substructure. They consist of the payload and, depending on the particular payload, of 
an EoD (SoD is not used). 


Section 4.5 describes the payload, which consists of the Commands and Responses. 


If present, the EoD contains a two-byte checksum referred to as CRC. A. The CRC A is defined 
as a function of k data bits. The number of bits k is a multiple of eight. Input for CRC A 
calculation is the payload. 


Figure 6 illustrates the NFC-A data and payload format for a standard frame. Table 4 shows the 
cases in which the EoD is present. 


Data 
Payload (Command or Response) [EoD] 
Byte 1 Byte 2 ues Byte n [CRC A1] [CRC A2] 


Figure 6: Data and Payload Format - NFC-A Standard Frame 


Data embedded in NFC-A short frames or NFC-A bit oriented SDD frames do not have SoD and 
EoD. 
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Requirements 15: Data and Payload Format - NFC-A 
Poll and Listen Mode 


4.4.1.1 If required according to Table 4, the payload MUST be followed by an EoD at the 
position, as indicated in Figure 6. The EoD MUST contain a CRC A. 


4.4.1.2 The CRC A MUST be calculated as defined in [ISO/IEC 13239], but the initial 
register content MUST be 6363h and the register content MUST not be inverted 
after calculation. CRC. A1 is the LSB and CRC . A2 is the MSB. 


4.4.1.3 The NFC Forum Device MUST compare the received CRC_A with the CRC A 
calculated according to Requirement 4.4.1.2. If different, then the NFC Forum 
Device MUST resort to exception processing with a Transmission Error. 


4.5 Command Set 


Payload exchanged between NFC Forum Devices consists of Commands and Responses. Table 4 
lists the Commands that are available to the NFC Forum Device configured for NFC-A 
Technology. For each Command, the corresponding Response is indicated. Furthermore, Table 4 
shows the frame type that a specific Command is embedded in and whether an EoD is present. 
Refer to Section 4.3 for the definition of NFC-A frames. 


Table 4: NFC-A - Command Set 


Command Response EoD Present Frame Type 
ALL REQ, SENS REQ No Short Frame 
SENS RES No Standard Frame 
SDD REQ No Bit Oriented SDD Frame 
SDD RES No Bit Oriented SDD Frame 
SEL REQ Yes Standard Frame 
SEL RES Yes Standard Frame 
SLP REQ Yes Standard Frame 


Requirements 16: NFC-A - Command Set 
Poll and Listen Mode 


4.5.1.1 Commands and Responses MUST be transmitted in compliance with Table 4. 


4.6 ALL REQ and SENS REQ 


The ALL. REQ and SENS. REQ Commands are sent by the NFC Forum Device in Poll Mode to 
probe the Operating Field for NFC Forum Devices in Listen Mode configured for NFC-A 
Technology. 
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4.6.1 ALL REQ Command 
Table 5 shows the format of the ALL. REQ Command. 
Table 5: Format of ALL REQ 


b7 b6 b5 b4 b3 b2 bi Meaning 
1 0 1 0 0 1 0 52h = ALL. REQ 


4.6.2 SENS REQ Command 
The format of the SENS_REQ Command is specified in Table 6. 
Table 6: Format of SENS_ REQ 


b7 b6 b5 b4 b3 b2 bi = Meaning 
0 1 0 0 1 1 0 26h = SENS_REQ 


4.6.3 SENS_RES Response 


In response to an ALL_REQ and SENS_REQ Command from the NFC Forum Device in Poll 
Mode, an NFC Forum Device in Listen Mode returns a SENS_RES Response with a length of 2 
bytes, depending on its state. (See [ACTIVITY] for more details.] The SENS_RES Response is 
coded as specified in Table 7 and Table 8. 


Table 7: Byte 1 of SENS_RES 
b8 b7 b6 b5 b4 b3 b2 bi Meaning 


0 0 NFCID1 size: single (4 bytes) 
0 1 NFCID1 size: double (7 bytes) 
1 0 NFCID1 size: triple (10 bytes) 
1 1 RFU 
0 RFU 

1 0 0 0 0 Bit frame SDD 

0 1 0 0 0 Bit frame SDD 

0 0 1 0 0 Bit frame SDD 

0 0 0 1 0 Bit frame SDD 

0 0 0 0 1 Bit frame SDD 

0 0 0 0 0 Bit frame SDD (identifies a Type 1 Tag 

platform) 
all other values RFU 
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Table 8: Byte 2 of SENS RES 


b8 b7 b6 b5 b4 b3 b2 b1 Meaning 
0 0 0 0 RFU 
1 1 0 0 Type 1 Tag platform configuration 


all other values Other than Type 1 Tag platform configuration 


Requirements 17: NFCID1 Length 


Poll Mode Listen Mode 

4.6.3.1 The NFC Forum Device MUST 4.6.3.2 The NFCID1 of the NFC Forum 
accept an NFCIDI of 4, 7, or Device MUST have a length of 4, 7, 
10 bytes. or 10 bytes. 


NOTE In [ISO/IEC 18092], the NFCID1 is specified to be only 4 bytes long. 
Requirement 4.6.3.2 overrules this restriction. 


Requirements 18: Type 1 Tag Platform Configuration 


Poll Mode Listen Mode 


The NFC Forum Device MAY be configured for 
Type 1 Tag platform and set b5-b1 of Byte 1 to 
00000b and b4-b1 of Byte 2 to 1100b 
accordingly. 


4.6.3.3 The NFC Forum Device MUST 
treat a SENS RES Response as 
Protocol Error: 


e With b5-b1 of Byte 1 set to 
00000b, but b4-b1 of Byte 2 
set to a value different from 
1100b or 

e With b4-b1 of Byte 2 set to 
1100b, but b5-b1 of Byte 1 
set to a value different from 
00000b 


NOTE Requirement 4.6.3.3 extends [ISO/IEC 18092]. 


47  SDD REQ 


The SDD_REQ Command is used to obtain the NFCID1 of an NFC Forum Device in Listen 
Mode and to detect whether more than one device of the same Technology is in the Operating 
Field of the NFC Forum Device in Poll Mode. Furthermore, the SDD REQ Command is used for 
collision resolution if there is more than one NFC Forum Device in Listen Mode in the Operating 
Field. Refer to [ACTIVITY] for details regarding the collision resolution mechanism. 
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4.7.1  SDD REQ Command 
Table 9 specifies how the SDD REQ Command is coded. 
Table 9: Format of SDD REQ Command 


Byte 1 Byte 2 n data bits 
SEL CMD SEL PAR data bit 1 ... data bit n 


The SEL. CMD byte indicates the cascade level (CL) of the NFCID1 requested by the NFC 
Forum Device in Poll Mode and is coded as shown in Table 10. 


Table 10: Format of SEL CMD 


b8 b7 b6 b5 b4 b3 b2 bi Meaning 
1 0 0 1 0 0 1 1 93h: SDD_REQ CL1 


1 0 0 1 0 1 0 1 95h: SDD_REQ CL2 


1 0 0 1 0 1 1 1 97h: SDD_REQ CL3 


all other values RFU 


The SEL_PAR byte indicates the length of the SDD_REQ Command, including the SEL_CMD 
and SEL_PAR byte, and therefore, it also indicates the number of data bits following the 
SEL_PAR byte. 


The upper 4 bits are called “byte count” and specify the integer part of the number of data bits 
transmitted by the NFC Forum Device in Poll Mode (including SEL_CMD and SEL_PAR) 
divided by 8. Consequently, the minimum value of “Byte count” is 2. A complete NFCID1, 
including checksum, has a length of 5 bytes, and therefore, the maximum value of “Byte count” is 
7. The byte count format is shown in Table 11. 


The lower 4 bits are called “bit count” and specify the number of data bits transmitted by the NFC 
Forum Device in Poll Mode modulo 8. The bit count format is shown in Table 12. 


For example, if SEL_PAR equals 20h, then no data bits are following. If SEL_PAR equals 35h, 
then 13 data bits are following. 


Table 11: Format of SEL_PAR (Upper 4 Bits) 


b8 b7 b6 b5 Meaning 
Byte count = 2 


Byte count = 3 


Byte count = 5 


Byte count = 6 


O|ocoococcoc'c 
^ÀDiÍÓimÍ|BImÍ|o|io 
Lal ka li el el tal rh 


0 
1 
0 Byte count = 4 
1 
0 
1 Byte count - 7 
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Table 12: Format of SEL PAR (Lower 4 Bits) 


b4 b3 b2 b1 Meaning 

0 0 0 0 Bit count = 0 
0 0 0 1 Bit count = 1 
0 0 1 0 Bit count = 2 
0 0 1 1 Bit count = 3 
0 1 0 0 Bit count = 4 
0 1 0 1 Bit count = 5 
0 1 1 0 Bit count = 6 
0 1 1 1 Bit count = 7 


The data bits following the SEL_PAR contain the first n bits of an NFCID1 in the cascade level 
as specified by the SEL_CMD byte. n is calculated by the value of SEL_PAR. The SDD_REQ 
Command contains a maximum of 39 data bits, excluding the SEL_CMD and the SEL_PAR. 


An NFC Forum Device in Listen Mode that receives the SDD_REQ Command compares its 
NFCID1 with the data bits received. If the first n bits of its NFCID1 in the respective cascade 
level are equal to the n data bits of the SDD_REQ Command, then this NFC Forum Device 
responds to the SDD_REQ Command. Otherwise, the SDD_REQ Command is ignored by the 
NFC Forum Device in Listen Mode. 
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4.7.1.1 


4.7.1.3 


NFC-A Technology 


Requirements 19: Format of SDD REQ Command 


The NFC Forum Device MUST 
set SEL. CMD to a value that is 
compliant with Table 10. 


If the NFC Forum Device does 
not support collision resolution, 
then the following applies: 


e The NFC Forum Device 
MUST set SEL PAR to a 
value that is compliant with 
the length of the SDD REQ 
Command. The SEL PAR 
value MUST be 20h. 


If the NFC Forum Device 
supports collision resolution, then 
the following applies: 


e The NFC Forum Device 
MUST set SEL PAR to a 
value that is compliant with 
the length of the SDD REQ 
Command. The minimum 
SEL PAR value MUST be 
20h. The maximum 
SEL PAR value MUST be 
67h. 


NFC Digital Protocol 


Listen Mode 


4.7.1.2 


4.7.1.4 


The NFC Forum Device MUST be 
ready to receive a SEL. CMD 
value that is compliant with 

Table 10. 


The NFC Forum Device MUST 
treat a SEL. CMD value not 
compliant with Table 10 as 
Protocol Error. 


The NFC Forum Device MUST be 
ready to receive a SEL. PAR value 
that is compliant with the length of 
the SDD REQ Command. 

The NFC Forum Device MUST be 
ready to receive a minimum 

SEL PAR value of 20h. 

For collision resolution, the NFC 
Forum Device MUST be ready to 
receive a maximum SEL PAR 
value of 67h. 

The NFC Forum Device MUST 
assign a Protocol Error to a 

SEL PAR value that is not 
allowed. 
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4.7.2  SDD RES Response 


In response to a SDD REQ Command with a SEL. PAR value equal to 20h, all NFC Forum 
Devices in Listen Mode in the Operating Field transmit the requested cascade level of their 
NFCID1 (NFCID1 CLn, with n=1, 2 or 3). The NFCID1 of an NFC Forum Device in Listen 
Mode consists of 4, 7, or 10 bytes. The length of the Response containing a complete NFCID1 
cascade level (i.e., NFCID1 CL1, or NFCID1 CL2, or NFCID1 CL3) is always 5 bytes. The 
coding of the Response depends on the value of the SEL CMD byte and the size of the NFCID1. 
Table 13 specifies how to code the SDD_RES Response containing a complete NFCID1 cascade 


level. 
Table 13: SDD RES Response (NFCID1 CLn + BCC) 


SEL CMD NFCID1 Size SDD RES Response 


93h 4 CL 1: nfcid1, nfcid1, nfcid1; nfcid1; BCC 
93h 24 CL1: CT nfcid1, nfcid1, nfcid1; BCC 
95h 7 CL2: nfcid1; nfcid1, nfcid15 nfcid1, BCC 
95h >7 CL2: CT nfcid1, nfcid1, nfcid1, BCC 
97h 10 CL3: nfcid1, nfcid1; nfcid1, nfcid1, BCC 


e nfcid1, is the n" byte of the complete NFCID1, with nfcid1 being the most significant 
byte. 

e CT is the cascade tag. 

e BCC is an exclusive-OR over the first 4 bytes of the SDD_RES Response. 


Table 14 specifies the content of nfcid1 in the case of a single size NFCID1. 


Table 14: nfcid1, for Single-size NFCID1 


nfcid1, Description 

08h nfcid1, to nfcid13 are dynamically generated 

xOh to x7h Fixed diversified number (the assignment is out of scope of this 
x9h to xEh specification) 


18h, 28h, 38h, 48h, 58h, 68h, RFU 
78h, 88h, 98h, A8h, B8h, 

C8h, D8h, E8h, F8h 

xFh 
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Requirements 20: NFCID1 
Listen Mode 


4.7.2.1 The NFCID1 can be dynamically generated by the NFC Forum Device. If 
dynamically generated by the NFC Forum Device, the length of the NFCID1 MUST 
be limited to 4 bytes. 


4.7.2.2 A dynamically generated NFCID1 MUST be generated only on state transition from 
POWER-OFF to IDLE state and if an RLS REQ Command is received (see 
[ACTIVITY] for the NFC Forum Device state machine). 


4.7.2.3 The nfcid1, for a single-size NFCID1 MUST be coded as specified in Table 14. 


4.7.2.4 The NFC Forum Device MUST set nfcid1, of a single-size NFCID1 and nfcid1; of 
a double-size NFCID1 to a value different from 88h. 


Requirements 21: Format of SDD RES Response (Complete and Incomplete NFCID1) 
Poll Mode Listen Mode 


The NFC Forum Device MAY treat a 4.7.2.5 The NFC Forum Device MUST set CT to 
SDD RES Response with a CT value a value of 88h. 


that is inconsistent with the length of 
the NFCID1 as Protocol Error. 


Requirements 22: Format of SDD RES Response (Complete NFCID1 Only) 


Poll Mode Listen Mode 

4.7.2.6 The NFC Forum Device 4.7.2.7 The NFC Forum Device MUST calculate 
MUST verify the BCC a BCC as exclusive-or over the first 4 
included in the SDD RES bytes of the SDD. RES Response 
Response. The NFC Forum (NFCID1 CL n). 


Device MUST treat an 
incorrect BCC as a 
Transmission Error. 
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In response to an SDD_REQ Command with a SEL. PAR value different from 20h only those 
NFC Forum Devices in Listen Mode in the Operating Field respond to the Command that fulfill 
the following requirement: 


e The first n bits of the NFCID1 in the respective cascade level are equal to the n data bits of 
the SDD_REQ Command following the SEL. PAR. 
Otherwise, the SDD REQ Command is ignored by the NFC Forum Device in Listen Mode. 


NFC Forum Devices in Listen Mode fulfilling this requirement return the remaining bits of the 
requested cascade level of their NFCID1 (NFCID1 CLn, with n=1, 2, or 3). 


Figure 7 illustrates an example. The NFC Forum Device in Poll Mode transmits an SDD REQ 
Command with SEL. CMD set to 93h, indicating the request for NFCID1 in cascade level 1. 
SEL PAR, set to 36h, indicates that 14 data bits are following (1 byte + 6 bits). NFC Forum 
Devices in Listen Mode, having an NFCID1 with the first 14 bits being equal to the 14 data bits 
sent in the SDD REQ Command, respond by sending the 26 remaining bits of their NFCID1. 


nfcid1o nfcid14 nfcid1s nfcid13 BCC 


oa]. jee[pijpz[pSb4]s]be[b]be|pi| ` bei ` bn — el 


[SEL_GMD (93) | SEL_PAR (16) i| — Fbäklskztzsd 
SDD_REQ Command psi — pe — spi — H 


SDD RES Response 


Figure 7: Example: SDD REQ with 14 Data Bits of NFCID1 CL1 (4 Bytes Size) and 
SDD RES 
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Requirements 23: Format of SDD RES Response (Incomplete NFCID1 Only) 


Poll Mode 


4.7.2.8 


4.7.2.10 


Listen Mode 


The NFC Forum Device MUST be 4.7.2.9 
ready to receive an SDD RES 

Response containing 40-n data 

bits, where n is the number of data 

bits following the SEL PAR in the 

SDD REQ Command previously 


sent. 


The NFC Forum Device MUST 
treat an SDD RES Response 
containing a different number of 
data bits as Protocol Error. 


The NFC Forum Device MUST 
verify the BCC included in the 
SDD RES Response. Verification 
data MUST be the first 4 bytes of 
the NFCID1 CL n (i.e., the 
concatenation of the data bits 
following the SEL. PAR in the 
preceding SDD REQ Command 
and the SDD. RES Response 
excluding the BCC). 


The NFC Forum Device MUST 
treat an incorrect BCC as a 
Transmission Error. 


4.7.2.11 


If the first n bits of the NFC 
Forum Device's NFCID1 in the 
respective cascade level are equal 
to the n data bits following the 
SEL PAR in the preceding 

SDD REQ Command, then the 
NFC Forum Device MUST return 
the remaining 40-n bits of its 
NFCID1 in the respective cascade 
level. 


Otherwise, the NFC Forum 
Device MUST ignore the 
SDD REQ Command. 


The NFC Forum Device MUST 
calculate a BCC as exclusive-or 
over the first 4 bytes of the 
NFCID1 CLn (from which a part 
is returned in the SDD RES 
Response). 


4.8 SEL REQ 


Use the SEL. REQ Command to select the NFC Forum Device in Listen Mode by means of its 
NFCIDI. 


4.8.1 SEL REQ Command 
Table 15 specifies the code for the SEL. REQ Command. 


Table 15: Format of SEL REQ Command 
Byte 1 Byte 2 
SEL CMD 70h 


Bytes 3- 6 
NFCID1 CLn 


Byte 7 
BCC 


The SEL. CMD byte is coded as is shown in Table 10. 
BCC is a checksum calculated as exclusive-or over the 4 bytes of the NFCID1 CLn. 
The format of NFCID1 CLn is specified in Table 16. 
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Table 16: NFCID1 CLn 


SEL CMD  NFCID1 Size NFCID1 CLn 


93h 4 CL1: nfcid1, nfcid1, nfcid1; nfcid1; 
93h >4 CL1: CT nfcid1, nfcid1, nfcid1, 
95h 7 CL2: nfcid1; nfcid1, nfcid1, nfcid1, 
95h 27 CL2: CT nfcid1,; nfcid1, nfcid15 
97h 10 CL3: nfcid1, nfcid1; nfcid1, nfcid1, 


nfcid1, is the n" byte of the complete NFCID1, with nfcid1, being the most significant byte. 


4.8.2 SEL RES Response 


The NFC Forum Device in Listen Mode transmits the SEL. RES Response in response to a 
SEL REQ Command. The length of the SEL. RES Response is one byte. Table 17 specifies the 
format of the SEL. RES Response. 


Table 17: Format of SEL RES Response 


b8 b7 b6 b5 b4 b3 b2 b1 Meaning 


x Any value 


X X If b3 is set to 1b: 
e Any value 


If b3 is set to Ob: 
e 00b: Configured for Type 2 Tag platform 


e 01b: Configured for Type 4A Tag platform, 
compliant with [ISO/IEC 14443] 


e 10b: Configured for the NFC-DEP Protocol 


e 11b: Configured for the NFC-DEP Protocol and 
Type 4A Tag platform 


X x Any value 


x Cascade bit 
e 1b: NFCID1 not complete 


e Ob: NFCID1 complete 


x x Any value 


NOTE The definition of SEL RES in Table 17 extends the definition of SEL. RES in 
[ISO/IEC 18092]. 
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Requirements 24: SEL RES Response 


Poll Mode Listen Mode 

4.8.2.1 The NFC Forum Device MUST 4.8.2.2 The NFC Forum Device configured 
treat a SEL. RES Response with for the Type 2 Tag platform MUST 
b3 set to Ob and b6-b7 set to 00b set b6-b7 of the SEL RES 
as coming from an NFC Forum Response to 00b in the last cascade 
Device configured for the Type 2 level (i.e., when the NFCIDI is 
Tag platform, and MUST act as complete). 
specified in [ACTIVITY ]. 

4.8.2.3 The NFC Forum Device MUST 4.8.2.4 The NFC Forum Device configured 
treat a SEL. RES Response with for the Type 4A Tag platform 
b3 set to Ob and b6-b7 set to O1b MUST set b6-b7 of the SEL. RES 
as coming from an NFC Forum Response to 01b in the last cascade 
Device configured for the Type level (i.e., when the NFCIDI is 
4A Tag platform, and MUST act complete). 
as specified in [ACTIVITY ]. 

4.8.2.5 The NFC Forum Device MUST 4.8.2.6 The NFC Forum Device configured 
treat a SEL. RES Response with for the NFC-DEP Protocol MUST 
b3 set to Ob and b6-b7 set to 10b set b6-b7 of the SEL RES 
as coming from an NFC Forum Response to 10b in the last cascade 
Device configured for the NFC- level (i.e., when the NFCIDI is 
DEP Protocol, and MUST act as complete). 
specified in [ACTIVITY ]. 

4.8.2.7 The NFC Forum Device MUST 4.8.2.8 The NFC Forum Device configured 
treat a SEL. RES Response with for both the Type 4A Tag platform 
b3 set to Ob and b6-b7 set to 11b and the NFC-DEP Protocol MUST 
as coming from an NFC Forum set b6-b7 of the SEL RES 
Device configured for both the Response to 11b in the last cascade 
Type 4A Tag platform and the level (i.e., when the NFCIDI is 
NFC-DEP Protocol, and MUST complete). 
act as specified in [ACTIVITY ]. 

4.9 SLP REQ 


Use the SLP. REQ Command to put the NFC Forum Device in Listen Mode in the SLEEP state 


(see [ACTIVITY] for the NFC Forum Device state machine). 


The SLP. REQ Command consists of 2 bytes. Table 18 specifies the format of the SLP. REQ 


Table 18: Format of SLP REQ Command 


4.9.1 SLP REQ Command 
Command. 

Byte 1 Byte 2 

50h 00h 


NFC Digital Protocol 
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4.9.2 SLP_REQ Response 
The NFC Forum Device in Listen Mode does not respond to an SLP REQ Command. 


Requirements 25: GLP REQ Response 


Poll Mode Listen Mode 

4.9.2.1 The NFC Forum Device 4.9.2.2 The NFC Forum Device MUST not 
MUST always treat the respond to an SLP REQ Command. 
SLP REQ Command as 
acknowledged by the NFC 
Forum Device in Listen 
Mode. 


4.10 Timing Requirements 


This section specifies the requirements for the different guard times and Frame Delay Times for 
NFC-A Technology. 


NOTE The term “Frame Response Time" as used in [ISO/TEC. 18092] is referred to as 
*Frame Delay Time" in this document. 


4.10.1 Frame Delay Time Poll—Listen 


The Frame Delay Time Poll—Listen (FDTA, Listen) is the time between a Poll Frame and a Listen 
Frame. The time between the minimum value FDTa visten,min and the maximum value 

FDT A, isrEN, Max defines the time interval in which a Listen Frame is allowed to be sent by an 
NFC Forum Device in Listen Mode in response to a Poll Frame of an NFC Forum Device in Poll 
Mode. 


For NFC-A Technology, FDT a visten depends on the logic value of the last bit before the EoF 
transmitted by the NFC Forum Device in Poll Mode, as illustrated in Figure 8. 
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FDTa Listen 


« » 
i‘ WS d 1bd > 1bd 
Logic "1" transmitted | EoF transmitted by SoF transmitted by 
by NFC Forum NFC Forum Device NFC Forum Device 
Device in Poll Mode in Poll Mode in Listen Mode 
(a) Last bit before EoF is Logic "1" 
FDTa.isten 
« >) 
Ead 
a E b 1 bd Pj 1bd 
Logic "0" transmitted | EoF transmitted by SoF transmitted by 
by NFC Forum NFC Forum Device NFC Forum Device 
Device in Poll Mode in Poll Mode in Listen Mode 


(b) Last bit before EoF is Logic "0" 


Figure 8: FDT a visten 


Table 19 shows the values FDTa tisten can take depending on the logic value of the last data bit 
transmitted by the NFC Forum Device in Poll Mode. The value of n is an integer and depends on 
the Command type transmitted within a Poll Frame. Section 4.5 defines the commands. 


Table 19: FDT4, sre and Logic State of Last Data Bit 


Logic State FDT,isrEN 
“<Q” n bd + 20/fc 
«1" n bd + 84/fc 


FDT a.isten,min follows the equations in Table 19 with a specific value of n, as shown in 
Table 20. 


Table 20: FDTacisten min and Command Type 


Command Type n 
ALL REQ 9 
SENS REQ 

SDD REQ 

SEL REQ 

All other Commands 29 
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If the Poll Frame contains an ALL. REQ, SENS REQ, SDD REQ, or SEL REQ Command, then 
FDT; visten,max is equal to FDTA i isrEv uin In this case, the Listen Frame is sent by the NFC 
Forum Device in Listen Mode at a specific point of time. 


Requirements 26: FDT,, isten 


Poll Mode Listen Mode 

4.10.1.1 Following the end of a Poll 4.10.1.2 Following the receipt of a Poll 
Frame, the NFC Forum Device Frame, the NFC Forum Device 
MUST be ready to receive the MUST align the first modulation 
start of a Listen Frame at a time edge within the start bit of a Listen 
aligned to the grid as defined in Frame to the grid as defined in 
Figure 8, Table 19, and Table 20. Figure 8, Table 19, and Table 20. 

4.10.1.3 For the Commands ALL. REQ, 4.10.1.4 Forthe Commands ALL. REQ, 
SENS REQ, SDD REQ, and SENS REQ, SDD REQ, and 
SEL REQ, the NFC Forum SEL REQ, the NFC Forum Device 
Device MUST treat receipt of a MUST always respond exactly at 
Listen Frame at a time after FDT A, isrEN MIN as defined in 
FDT a visten,min aS a Timeout Table 19 and Table 20 (i.e., 
Error Oe, FDOT, Listen,max equals FDT 4 visten,max equals 
FDT A, isrEN Mix). FDT a visten,min)- 


Requirements 27: Tolerance 


Listen Mode 


4.10.1.5 The NFC Forum Device in Listen Mode MUST detect the end of the last V2 
transmitted by the NFC Forum Device in Poll Mode within the FDT tolerance t4. 
Refer to [ANALOG] for the definition of ta. 


Requirements 28: FDT,, srENMIN 


Poll Mode 


4.10.1.6 Following the end of a Poll Frame, the NFC Forum Device MUST ignore any 
response during a time FDTjisreN Mig — 128/fc. 


The NFC Forum Device in Listen Mode is not allowed to produce any detectable disturbance 
during a minimum time period Lon «i, before sending a Response. 
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FDTaisten 


FDTauisten,min — 128/f; tnn.min (= tnn) 


Last lower level 


(NFC Forum Device SoF , 
in Poll Mode) (NFC Forum Device 
in Listen Mode 
(a) FDTausreN >= (FDTa,uisten,min — 128/f,) + tnn ) 
FDTausten 
» 
FDTA LisTEN,;MIN i 128/f, » Lu mm (= FDTauisten a (FDTA,LisTEN,MIN T 128/fe)) 


Last lower level 


(NFC Forum Device SoF 
in Poll Mode) (NFC Forum Device 
in Listen Mode) 


(b) FDTausten < (FDTauisten.min — 128/fc) + tnn 
Figure 9: t;, i; for NFC-A 


Requirements 29: tnn, min - NFC-A 
Listen Mode 


4.10.1.7. The NFC Forum Device MUST not produce any detectable disturbance during a period 
of at least Un, min; defined as the minimum of FDTaA, isrEN = (FDT 4. LISTEN, MIN = 128/fc) 
and tnn, before sending a Response. tnn,min MUST be measured before the start of the 
SoF of the Listen Frame, as shown in Figure 9. 


Refer to Appendix A.1 for the value of tnn. 


The exact quantity of what constitutes ‘any detectable disturbance’ is not defined by this version of 
the specification. 


4.10.2 Frame Delay Time Listen Poll 


The Frame Delay Time Listen Poll (FDT, rou) is the time between a Listen Frame and a Poll 
Frame. The minimum value FDTApoi iu defines the time an NFC Forum Device in Poll Mode 
has to wait before sending a new Poll Frame after receipt of a Listen Frame. A maximum value 
FDT; ro max is not defined. 


For NFC-A Technology, the definition of FDTApoi, depends on the logic value of the last data 
bit of the Listen Frame transmitted by the NFC Forum Device, as shown in Figure 10. However, 
FDT; poui is not restricted to certain discrete values like FDT, usten. 
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FDT Pou 
>| 
«— —— — —— — éi 

ig 1bd WR 1 bd g 1 bd 

Logic "1" End of Sequence Start of Frame (SoF) 

transmitted by (EoS) transmitted by transmitted by 

NFC Forum Device NFC Forum Device NFC Forum Device 

in Listen Mode in Listen Mode in Poll Mode 


(8) Last transmitted data bit is Logic "1" 


FDTa,poit 
e 
« 1 bd Kb 1bd | 1 bd 
Logic "0" End of Sequence Start of Frame (SoF) 
transmitted by (EoS) transmitted by transmitted by 
NFC Forum Device NFC Forum Device NFC Forum Device 
in Listen Mode in Listen Mode in Poll Mode 
(b) Last transmitted data bit is Logic "0" 
Figure 10: FEDTA rou. 
Requirements 30: EDT, Got Mm 
Poll Mode Listen Mode 
4.10.2.1 ` Following the end of a 4.10.2.2 The NFC Forum Device MUST be ready to 
Listen Frame, the NFC receive the start of a new Poll Frame no later 
Forum Device MUST than FDT, Got after the end of a Listen 
wait at least for Frame. 
FDT a ou um before If the start of a new Poll Frame is received before 


transmitting the start of a EDIT sot ta, then the NFC Forum Device MAY treat this 


new Poll Frame. Refer as a Transmission Error. 
to Appendix A.1 for the 


value of FDTA Pottmin- 


A specific value for FDTApoiri,ui is defined for the re-activation of the NFC Forum Device in 
Listen Mode following a DSL. RES Response (see Section 14.9.2), an RLS_RES Response (see 
Section 14.10.2), or an S(DESELECT) Response (see Section 13.2.7). 
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4.10.2.3 


NFC-A Technology 


Requirements 31: FDT 4 reactivation 


Following the end of a DSL_RES 
Response, an RLS_RES Response, 
or an S(DESELECT) Response, the 
NFC Forum Device MUST wait at 
least for FDT 4 REACTIVATION before 
transmitting the start of a new Poll 
Frame. 


Refer to Appendix A.1 for the value 
of FDT 4 reactivation- 


4.10.3 Guard Time 


This section specifies the guard time of Unmodulated Carrier after which the NFC Forum Device 
in Listen Mode must be ready to receive an ALL_REQ or SENS_REQ Command. 


Listen Mode 


4.10.2.4 


The NFC Forum Device MUST be 
ready to receive the start of a new 
Poll Frame no later than 

FDT 4 REACTIVATION after the end of a 
DSL_RES Response, an RLS_RES 
Response, or an S(DESELECT) 
Response. 


If the start of a new Poll Frame is received 
before FDT 4 REACTIVATION; then the NFC Forum 
Device MAY treat this as a Transmission Error. 


Requirements 32: Guard Time - NFC-A 


Listen Mode 


4.10.3.1 


When an NFC Forum Device in Listen Mode is exposed to an Unmodulated Carrier (see 
[ANALOG]), it MUST be ready to receive an ALL. REQ or SENS REQ Command 


within a guard time GT. 


Refer to Appendix A for the value of GT4. 
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5 NFC-B Technology 


This section specifies the NFC-B Technology-related features of the NFC Forum Device. 
Information defined elsewhere has been included for readability reasons. 


If not explicitly stated otherwise, [ISO/IEC 14443] is normative reference for this section. 
Deviations from and restrictions of [ISO/TEC 14443] are indicated within the text on the topics 
for which deviations and restrictions apply. 


Implementation of NFC-B Listen Mode is optional. However, if implemented, then it has to be 
implemented as specified here (see Requirements 1.10.1.1). 


5.1 Sequence Format 


This section describes the sequence format for NFC-B Technology. 


5.1.1 Poll—Listen Modulation 


In Poll Mode, the analog signal is modulated using NRZ-L coding based on the ASK 10% 
modulation principle. For details about the Modulation Index, refer to [ANALOG]. Figure 11 
illustrates NRZ-L coding. 


pattern H 


pattern L pattern H pattern H pattern H 


100% 


-100% 


Figure 11: NRZ-L Coding 


Using the modulation principle of NRZ-L coding with ASK modulation, the carrier amplitude is 
varied in order to define two particular patterns: L and H. 
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Requirements 33: Signal Patterns PollListen - NFC-B 


Poll Mode Listen Mode 

5.1.1.1 The NFC Forum Device MUST 5.1.1.2 The NFC Forum Device MUST 
build pattern L and pattern H as read pattern L and pattern H as 
follows: follows: 

e Pattern L: carrier low e Ifthe carrier is low 
(modulation applied) for the (modulation applied) for the 
full bit duration full bit duration, then the NFC 

e Pattern H: carrier high (no Forum Device MUST read this 

pattern L. 


modulation applied) for the full 

bit duration. e Ifthe carrier is high (no 
modulation applied) for the full 
bit duration, then the NFC 
Forum Device MUST read this 
as pattern H. 


e All other patterns MUST be 
treated as invalid patterns. 


5.1.2 Listen—-Poll Modulation 


In Listen Mode, the analog signal is modulated using NRZ-L with BPSK modulation (see 
Figure 12). 


pattern M pattern N pattern M pattern M pattern M 


100%- M LML LLN NNN LR WU o a a a o o o o o w a o a 
| | | 


A UU UU UU UU UU UU UU UU A UU UU 


-100% 


1 bd 
Figure 12: NRZ-L Coding with BPSK 


NRZ-L with BPSK modulation uses a phase shift (180°) of the subcarrier to define two particular 
patterns: N and M. 
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Requirements 34: Signal Patterns ListenPoll - NFC-B 


Poll Mode 


Listen Mode 


The NFC Forum Device MUST 


5.1.2.1 5.1.2.2 
read a subcarrier with phase OU for 


the full bit duration as pattern M. 
If there is a phase transition, then 


this marks the beginning of the 
pattern. 


The NFC Forum Device MUST 

build the following as pattern M: 

e Asubcarrier with phase (20 for 
the full bit duration. 

If this requires a phase transition, 

the phase transition MUST be at the 

beginning of the pattern. 


5.1.2.3 The NFC Forum Device MUST 
read a subcarrier with phase (2180? 


for the full bit duration as pattern N. 


5.1.2.4 


If there is a phase transition, then 
this marks the beginning of the 
pattern. 


All patterns different from 
pattern M and pattern N MUST be 
treated as invalid patterns. 


The NFC Forum Device MUST 

build the following as pattern N: 

e Asubcarrier with phase (0180? 
for the full bit duration. 

If this requires a phase transition, 

the phase transition MUST be at the 

beginning of the pattern. 


5.1.3 Synchronization 


Figure 13 and Figure 14 illustrate the different parameters used for NFC-B Technology signal 


synchronization and related signal timing parameters. 


No subcarrier 


| tusrENE | tesorr! 
Phase wt >a » 
Ending of b=0 | | 
Listen Frame 
= 180° 
- - 
| m FDTa pou (TR2) 
Pl B,POLL 
Amplitude 
Bosh t 100 96 
eginning o 
9 9 No modulation 
Poll Frame 


VTT f tpoLL,s,2 | 
>< pa 


SoS 


Figure 13: Synchronization and Timing Parameters between a Listen Frame and a Poll 


Frame 
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| tpoLL,E | 
Amplitude rt > 
Ending of 100 % | 
Poll Frame Unmodulated carrier 
- - 
: EoS | FDTa,uisrEN 
| TRO | TRL | tuisrEN si tuistens2 
rd - >< >< ra Fa 
SÉ =0° l i ; i m 
Beginning of ? EE Unmodulated start 
Listen Frame subcarrier bit : 
d — 180? ! — eee 
< > 
i SoS i 


Figure 14: Synchronization and Timing Parameters between a Poll Frame and a Listen 


Frame 


For the demodulator, the beginning of a signal is indicated by the SoS. 


Requirements 35: Synchronization Pol Listen - NFC-B 


Poll Mode Listen Mode 
5.1.3.1 The NFC Forum Device MUST 5.1.3.2 

code SoS as follows: 

e SoS: tpori sa With carrier low e 


(modulation applied), followed 
by tpoLL,s,2 with carrier high 
(no modulation applied) 
Refer to Appendix A.2 for the 
values of tpoLL,s,1 and tpoLL,s,2- 


NFC Digital Protocol 


The NFC Forum Device MUST 
decode SoS as follows: 


If the carrier is low 
(modulation applied) for 
tpoLL,s,1, followed by tpoii,s,2 
with carrier high (no 
modulation applied), then the 
NFC Forum Device MUST 
decode that as SoS. 
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Requirements 36: Synchronization ListenPoll - NFC-B 


Poll Mode 


5.1.3.3 For establishing phase reference 
20, the NFC Forum Device MUST 
proceed as follows: 


e After any Command from the 
NFC Forum Device, it MUST 
ignore any subcarrier generated 
by the NFC Forum Device in 
Listen Mode during a time 
TROwmin. 


e The subcarrier as detected 
during TR1 MUST be taken as 
phase reference OU. 

If a phase transition is detected before TR1yin, 
then the NFC Forum Device MAY resort to 
exception processing (Transmission Error). 

If at TR1max, no phase transition is detected, 
then the NFC Forum Device MAY resort to 
exception processing (Transmission Error). 


Listen Mode 


5.1.3.4 


For establishing phase reference 
(20, the NFC Forum Device MUST 
proceed as follows: 


After any Command from the 
NFC Forum Device in Poll 
Mode, a minimum guard time 
TROwin MUST apply in which 
the NFC Forum Device in 
Listen Mode MUST not 
generate a subcarrier. Refer to 
Appendix A.2 for the value of 
TROmmn. 


Following the guard time TRO, 
the NFC Forum Device MUST 
then generate a subcarrier with 
no phase transition for a 
synchronization time TR1. This 
establishes a subcarrier phase 
reference (20. 

Refer to Appendix A.2 for the 
minimum and maximum value 
of TR1 (TR1mn and TRí1max). 
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5.1.3.5 


If, after the synchronization time 
TR1, the NFC Forum Device 
detects: 


e a subcarrier phase transition O0 
to G0+180° 

e followed by a subcarrier with 
phase (207-180? for tusten,s,1 

e followed by a subcarrier phase 
transition (007-180? to G0 

e followed by the subcarrier with 
phase (20 for tusten,s,2 


then the NFC Forum Device MUST 
decode this as SoS. 


5.1.4 Pattern Synchronization 


NFC-B Technology 


Listen Mode 


5.1.3.6 


After the synchronization time TR1, 

the NFC Forum Device MUST code 

SoS as follows: 

e subcarrier phase transition OU 
to (20-180? 

e followed by a subcarrier with 
phase (207-180? for tusten,s,1 

e followed by a subcarrier phase 
transition (007-180? to 0 

e followed by subcarrier with 
phase (20 for tuisten,s,2 


Refer to Appendix A.2 for the 
values of tusten,s,1 and tuisten,s,2- 


Patterns are grouped in a pattern group that are 10 bit durations long. The separation between two 
pattern groups is defined as the Extra Guard Time (EGT). 


Requirements 37: NFC-B Pattern Group Separation 


Poll and Listen Mode 


5.1.4.1 The time between two consecutive pattern groups sent by the NFC Forum Device in 
Poll Mode to the NFC Forum Device in Listen Mode MUST be EG Teo, Refer to 
Appendix A.2 for the value of EGTpoit. 

5.1.4.2 The time between two consecutive pattern groups sent by the NFC Forum Device in 


Listen Mode to the NFC Forum Device in Poll Mode MUST be EGTi rev. Refer to 
Appendix A.2 for the value of EGT,jsrew. 


The separation between two patterns within a pattern group occurs according to the following 
requirements. 


Poll Mode 


5.1.4.3 


5.1.5 


Requirements 38: NFC-B Pattern Boundaries 


For Poll—Listen communication, 
pattern boundaries within a pattern 
group MUST occur between n bd + 
8/fc where n is the number of 
pattern boundaries after the start 
pattern falling edge (1 € n x 9). 


De-synchronization 


The end of a sequence is indicated by the EoS. 


NFC Digital Protocol 


Listen Mode 


5.1.4.4 


For Listen Poll communication, 
pattern boundaries within a pattern 
group MUST only occur at nominal 
positions of rising or falling edges 
of the subcarrier: n bd + 16/fc. 
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Requirements 39: De-synchronization Poll>Listen - NFC-B 


Poll Mode 


5.1.5.1 The NFC Forum Device MUST 
code EoS as follows: 


e EoS: tpo, with carrier low 
(modulation applied), followed 
by a transition to carrier high. 

Refer to Appendix A.2 for the value 

of tpoLL,E- 


Listen Mode 


5.1.5.2 


The NFC Forum Device MUST 
decode EoS as follows: 


e Ifthe carrier is low (modulation 
applied) for Gout. e, followed by 
a transition to carrier high (no 
modulation applied), then the 
NFC Forum Device MUST 
decode that as EoS. 


Requirements 40: De-synchronization Listen Poll - NFC-B 


Poll Mode 


5.1.5.3 If the NFC Forum Device detects: 
e a subcarrier phase transition O0 
to G0+180° 
e followed by the subcarrier with 
phase (207-180? for İLISTEN,E 
e followed by a subcarrier phase 
transition Ø0+180° to Ø 


then the NFC Forum Device MUST 
decode this as EoS. 


Listen Mode 


5.1.5.4 


The NFC Forum Device MUST 
code the following as EoS: 


e a subcarrier phase transition (0 
to (007-180? 

e followed by a subcarrier with 
phase (207-180? for İLISTEN,E 

e followed by a subcarrier phase 
transition Ø0+180° to Ø0 


Refer to Appendix A.2 for the value 
of tiisrEN,E- 


5.1.5.5 The NFC Forum Device MUST 
accept that the subcarrier is 
maintained on for a time tesorr after 
EoS by the NFC Forum Device in 
Listen Mode. 
After EoS, if the NFC Forum Device in Listen 
Mode maintains the subcarrier on for a time 
greater than the maximum value of trsorr, then 
the NFC Forum Device in Poll Mode MAY 
resort to exception processing (Transmission 
Error). 


NFC Digital Protocol 


5.1.5.6 


After EoS, the NFC Forum Device 
MUST maintain the subcarrier on 
for a time tfsopr and MUST turn 
the subcarrier off. 

Refer to Appendix A.2 for the value 
of tesorr. 
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5.2.1  PolloListen Coding Scheme 


NFC-B Technology 


The patterns L and H are used to code the digital alphabet Logic “0” and Logic “1”. 


Requirements 41: Bit Level Coding PollListen - NFC-B 


Poll Mode 


The NFC Forum Device MUST 
code Logic “0” and Logic “1” as 
follows: 


5.2.1.1 


e Logic "0": pattern L 
e Logic “1”: pattern H 


5.2.2  Listen—Poll Coding Scheme 


Listen Mode 


5.2.1.2 


The NFC Forum Device MUST 
decode Logic *0" and Logic *1" as 
follows: 

e If the NFC Forum Device 
detects pattern L, then it MUST 
decode this as Logic “0”. 

e If the NFC Forum Device 
detects pattern H, then it 


MUST decode this as Logic 
SITZ, 


Invalid patterns MAY be treated as 
Transmission Errors, or the device MAY use 
implementation dependent methods to decode 
an invalid pattern into a Logic *0" or Logic 


«1 DI 


Use patterns N and M to code the digital alphabet Logic “0” and Logic “1”. 


Requirements 42: Bit Level Coding Listen Poll - NFC-B 


Poll Mode 


The NFC Forum Device MUST 
decode Logic “0” and Logic “1” as 
follows: 


e Ifthe NFC Forum Device 
detects pattern N, then it MUST 
decode this as Logic “0”. 


e If the NFC Forum Device 
detects pattern M, then it 
MUST decode this as Logic 
«T. 
Invalid patterns MAY be treated as 
Transmission Errors or the device MAY use 
implementation dependent methods to decode 
an invalid pattern into a Logic *0" or 
Logic “1”. 


5.2.2.1 


Listen Mode 


5.2.2.2 


The NFC Forum Device MUST 
code Logic “0” and Logic “1” as 
follows: 


e Logic “0”: pattern N 
e Logic “1”: pattern M 
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5.3 Frame Format 


To transmit data, the NFC Forum Device configured for NFC-B Technology uses frames that are 
built from characters. This section defines the format of characters and frames. 


A character consists of a Logic “0” start bit, a Logic “1” stop bit and eight data bits. The stop bit, 
start bit, and each data bit has a length of one bit duration (bd**). Figure 15 shows the character 
format. 


Start lsb msb Stop 
b1 b2 b3 b4 b5 b6 b7 b8 
tm LO bd o> 


Figure 15: NFC-B - Character Format 
Requirements 43: Character Format - NFC-B Technology 


Poll and Listen Mode 


5.3.1.1 A character MUST consist of a start bit (Logic *0"), 8 data bits, and a stop bit (Logic 
“1”). The stop bit, start bit, and each data bit MUST be one bit duration (bd). 


Characters are sent as frames, as shown in Figure 16. 


n x (start bit 8 data bits stop bit) 


Start Stop |Start Stop Start Stop 
SPERFEFEMETEFEEEEREMED - TERREREREME 


1* byte 2™ byte n" byte 


Figure 16: NFC-B - Frame Format 
Requirements 44: Frame Format - NFC-B Technology 
Poll and Listen Mode 
5.3.1.2 A frame MUST consist of characters that are aligned as shown in Figure 16. 
NOTE The frame format defined in Figure 16 deviates from [ISO/TEC. 14443]. Sot and 


EoF as defined in [ISO/IEC 14443] are defined by this specification as SoS and EoS 
at the sequence layer. 


5.4 Data and Payload Format 


Data transmitted in an NFC-B frame have the following substructure. They consist of the payload 
and of an EoD (SoD is not used). 


The payload consists of the Commands and Responses described in Section 5.5. 


The EoD contains a 2-byte checksum referred to as CRC_B. The CRC_B is a function of k data 
bits, which is a multiple of 8. Input for CRC_B calculation is the payload. 


Figure 17 illustrates the NFC-B data and payload format. 
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Data 
Payload (Command or Response) EoD 
Byte 1 Byte 2 ET Byten CRC B1 |CRC B2 


Figure 17: Data and Payload Format - NFC-B 


Requirements 45: Data and Payload Format - NFC-B 
Poll and Listen Mode 


5.4.1.1 Data MUST be transmitted in frames as defined in Section 5.3. 


5.4.1.2 The payload MUST be followed by an EoD at the position, as indicated in Figure 17. 
The EoD MUST contain a CRC B. 


5.4.1.3 The CRC B MUST be calculated as defined in [ISO/IEC 13239]. The initial register 
content MUST be all ones (FFFFh). CRC B1 is the LSB and CRC B2 is the MSB. 


5.4.1.4 The NFC Forum Device MUST compare the received CRC_B with the CRC B 
calculated according to Requirement 5.4.1.3. If different, then the NFC Forum Device 
MUST resort to exception processing with a Transmission Error. 


5.5 Command Set 


Payload exchanged between NFC Forum Devices consists of Commands and Responses. 
Table 21 lists the Commands that are supported by the NFC Forum Device configured for NFC-B 
Technology. For each Command, the corresponding Response is indicated. 


Table 21: NFC-B - Command Set 


Command Response 
ALLB REQ, SENSB REQ SENSB RES 
SLOT MARKER SENSB RES 
(optional for Poll Mode) 
SLPB REQ SLPB RES 
NOTE The Commands and Responses listed in Table 21 have different names in 


[ISO/IEC 14443]: 
ALLB_REQ refers to WUPB, SENSB_REQ refers to REQB, SENSB RES refers to 
ATQB, SLPB REQ and SLPB RES refer to HLTB and its Response. 


5.6 ALLER REQ and SENSB REQ 


The ALLB. REQ and SENSB_REQ Commands are used by an NFC Forum Device in Poll Mode 
to probe the Operating Field for NFC Forum Devices in Listen Mode. 


5.6.1 ALLB REQ and SENSB REQ Command 
Table 22 defines the format of the ALLB_ REQ and SENSB REQ Commands. 


NFC Digital Protocol Page 52 


NFC-B Technology 


Table 22: ALLB REQ and SENSB REQ Command Format 
Byte 1 Byte 2 Byte 3 
05h AFI PARAM 


The components of this Command are defined as follows: 
AFI 
The AFI indicates the application family being selected. 


Requirements 46: AFI 


Poll Mode Listen Mode 

5.6.1.1 The AFI MUST be set to 00h. ` The NFC Forum Device MAY support an 
This selects all application ALLB REQ and a SENSB REQ with AFI 
families. different from 00h. 


PARAM 
Table 23 specifies the format of PARAM. 


Table 23: Format of PARAM Byte Included in ALLB REQ and SENSB REQ Command 


b8 b7 b6 b5 b4 b3 b2 bi Meaning 
0 0 RFU 


x Ob: Advanced protocol features not supported 
1b: Advanced protocol features supported 
x Ob: Extended SENSB_RES not supported 
1b: Extended SENSB_RES supported 
x 0b: SENSB_REQ 
1b: ALLB_REQ 


X X X Number of slots (N) 


The Number of slots (N) is used by the anticollision scheme defined in [ISO/IEC 14443]. The 
anticollision scheme is based on the definition of time slots in which NFC Forum Devices in 
Listen Mode are invited to respond. Table 24 specifies the coding of N. 
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Table 24: Coding of N 


b3 b2 b1 Meaning 


0 0 0 N=1 

0 0 1 N=2 

0 1 0 N=4 

0 1 1 N=8 

1 0 0 N=16 

1 0 1 RFU 

1 1 X RFU 

Requirements 47: Number of Slots (N) 

Poll Mode Listen Mode 

5.6.1.2 If the NFC Forum Device does 5.6.1.3 The NFC Forum Device MUST be 
not support collision resolution, ready to receive a value of N set to 
it MUST set N to 1. 1. For collision resolution, it MUST 
If the NFC Forum Device be ready to receive a value of N as 
supports collision resolution, it specified in Table 24. 
MUST set N to a value as 
specified in Table 24. 


Requirements 48: Listen Mode Handling of RFU Values of N 
Listen Mode 


5.6.1.4 A received RFU value of N MUST be treated by the NFC Forum Device in Listen 
Mode as N=16. 


Bit 5 indicates whether the NFC Forum Device in Poll Mode supports the extended SENSB. RES 
byte. The extended SENSB RES byte is an optional byte included in the SENSB_RES Response, 
coding the SFGI used by the NFC Forum Device in Listen Mode. 


Bit 6 indicates whether the NFC Forum Device in Poll Mode supports advanced protocol features 
(e.g., higher bit rates). 
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5.6.1.5 


NFC-B Technology 


Requirements 49: Support for Extended SENSB RES 


The NFC Forum Device MUST 
be ready to receive a 

SENSB RES Response with or 
without an extended SENSB. RES 
byte included. 


Listen Mode 


5.6.1.6 


When answering an ALLB. REQ 
or SENSB REQ Command with 
bit b5 set to Ob, indicating that the 
extended SENSB RES is not 
supported, the NFC Forum Device 


MUST not include the extended 
SENSB RES byte in its 
SENSB RES Response. 


When answering an ALLB_REQ or 

SENSB REQ Command with b5 set to 1b, 
indicating that the extended SENSB RES is 
supported, the NFC Forum Device MAY or 
MAY not include the extended SENSB RES 
byte in its SENSB RES Response. 


5.6.2  SENSB RES Response 
Table 25 defines the SENSB. RES format. 
Table 25: SENSB RES Format 
Byte 1 
50h 


Byte 2-5 
NFCIDO 


Byte6-9 Byte 10 - 12 or 13 


Application Data Protocol Info 


Byte 13 (i.e., the extended SENSB RES byte of the SENSB RES Response) is optional. If it is 
not used, then the SENSB RES consists of only 12 bytes. 


NFCIDO 


The NFCIDO is used to differentiate between NFC Forum Devices in Listen Mode during the 
Collision Resolution Activity. 


Requirements 50: NFCIDO in SENSB RES 
Listen Mode 


5.6.2.1 The NFCIDO MUST have a length of 4 bytes. The value of the NFCIDO MUST be 


fixed or dynamically generated by the NFC Forum Device. 


5.6.2.2 A dynamically generated NFCIDO MUST be generated only on state transition 
from POWER -OFF to IDLE state (see [ACTIVITY] for the NFC Forum Device state 
machine). 
Application Data 


The Application Data Field is used to inform the NFC Forum Device in Poll Mode which 
applications are installed on the NFC Forum Device in Listen Mode. 
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The Application Data is defined according to the ADC in the Protocol Info, which defines if 
either the CRC B compressing method (described below) or proprietary coding is used. 


When the CRC B compressing coding is used, the Application Data field contains the 
information shown in Table 26: 


Table 26: Application Data Format 


Byte 1 Byte 2 and 3 Byte 4 
AFI CRC B (AID) Number of applications 


Protocol Info 


The Protocol Info indicates the parameters supported by the NFC Forum Device in Listen Mode, 
as defined in Table 27. 


Table 27: Protocol Info Format 


Byte 4 
(optional) 
FO SFGI RFU 

(2 bits) | (4 bits) | (4 bits) 


Byte 1 Byte 2 


FSCI Protocol_Type | FWI ADC 
(4bits) | (4 bits) (4 bits) | (2 bits) 


e Bit Rate Capability 


Bit Rate Capability 
(8 bits) 


Table 28 specifies the bit rates supported by the NFC Forum Device in Listen Mode. Bits b7 
to b5 code the bit rate capability of the NFC Forum Device in Listen Mode for the direction 
from NFC Forum Device in Listen Mode to NFC Forum Device in Poll Mode 

(DusrENS Poi). The value 000b corresponds with DiisrEN S POLL = 1. The bits b3 to b1 code 
the bit rate capability of the NFC Forum Device in Listen Mode for the direction from NFC 
Forum Device in Poll Mode to NFC Forum Device in Listen Mode (Dot use), The value 
000b corresponds with Depots LisTEN =1. 
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Table 28: Bit Rates Supported by the NFC Forum Device in Listen Mode 


b8 b7 b6 b5 b4 b3 b2 b1 Meaning 


x If b8 = 1b, then only the same bit rate divisor for 
both directions is supported 
(Dusten+port=Dpottsusten)- 
If b8 = Ob, then a different bit rate divisor for each 
direction is supported. 


X DiisrEN POLL -8 supported, if bit is set to 1b. 


X DiisrEN S POLL =4 supported, if bit is set to 1b. 


x DiisrEN POLL -2 supported, if bit is set to 1b. 


0 RFU 


X Drot SLisTEN -8 supported, if bit is set to 1b. 


X DPoLL-LISTEN =4 supported, if bit is set to 1b. 


X DpoLLousten 72 supported, if bit is set to 1b. 


0 0 0 0 O O0 O0 O0 The NFC Forum Device supports only a bit rate 
of 106 kbits/s in both directions. 


Requirements 51: Bit Rates Supported by the NFC Forum Device in Listen Mode 


Poll Mode Listen Mode 
5.6.2.3 The NFC Forum Device MUST 5.6.2.4 In response to a SENSB_REQ 
support a bit rate of 106 kbits/s and ALLB_REQ with b6 of 
in both directions. PARAM byte set to 0b, the NFC 
The NFC Forum Device MAY support Forum Device MUST set bits b7 
higher bit rates. to b5 and b3 to b1 of the 


Bit_Rate_Capability equal to 0b, 
indicating that it supports only a 
bit rate of 106 kbits/s in both 
directions. 


The NFC Forum Device MAY indicate 
support for higher bit rates in response to a 
SENSB_REQ and ALLB_REQ with b6 of 
PARAM set to 1b. 


Requirements 52: Poll Mode Handling of RFU Value of b4 of Bit_Rate_Capability 
Listen Mode 


5.6.2.5 A received RFU value of b4 = 1b MUST be interpreted by the NFC Forum 
Device in Poll Mode as if b7 to b1 = 0000000b (only 106 kbits/s in both 
directions). 


NOTE Higher bit rates will be specified in next versions of this specification. 
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e FSCI 


FSCI contains the maximum frame size (FSC), coded as indicated in Table 29. The FSC 
defines the maximum size of a frame (in bytes) accepted by the NFC Forum Device in Listen 
Mode. 


Table 29: FSCI to FSC Conversion 


FSCI Oh ih 2h 3h 4h 5h 6h 7h 8h  9h-Fh 
FSC (bytes) 16 24 32 40 48 64 96 128 256 RFU 


Requirements 53: FSC 


Poll Mode Listen Mode 

5.6.2.6 The NFC Forum Device MUST _ 5.6.2.7 The NFC Forum Device MUST 
send frames with a number of accept frames with a number of 
data bytes less than or equal to data bytes less than or equal to 
FSC. FSC. The NFC Forum Device 


MUST resort to exception 
processing (Protocol Error) if it 
receives a frame with more than 
FSC data bytes. 


5.6.2.8 The NFC Forum Device MUST 5.6.2.9 The FSC supported by the NFC 


be capable of sending frames in Forum Device MUST be at least 

accordance with an FSC greater FSCun. 

than or equal to FSCmn. Refer to Appendix A.2 for the 
value of FSCun. 


Requirements 54: FSCI 


Listen Mode 


5.6.2.10 The NFC Forum Device MUST set FSCI greater than or equal to the value 
corresponding to FSCyiy with a maximum value of 8h. Refer to Appendix A.2 
for the value of FSCwin. Refer to Table 29 for FSCI to FSC conversion. 


Requirements 55: Poll Mode Handling of RFU Values of FSCI 
Poll Mode 


5.6.2.11 A received value of FSCI = 9h-Fh MUST be treated by the NFC Forum Device 
as FSCI = 8h. 
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e Protocol Type 


Protocol Type indicates the protocol type and the minimum TR2 (see Figure 13) supported 
by the NFC Forum Device in Listen Mode, as shown in Table 30. 


Table 30: Protocol Type 


b4 b3 b2 bi Meaning 
0 RFU 


X X Minimum TR2 


Ob: NFC Forum Device in Listen Mode not compliant with 
[ISO/IEC 14443] 


1b: NFC Forum Device in Listen Mode compliant with 
[ISO/IEC 14443] 


Requirements 56: Protocol Type Supported by the NFC Forum Device in Listen Mode 


Poll Mode Listen Mode 

5.6.2.12 The NFC Forum Device 5.6.2.13 The NFC Forum Device MUST 
MUST be ready to receive the indicate support for 
Protocol Type with bit b1 set [ISO/IEC 14443] by setting bit b1 
to 1b. to 1b. 


The NFC Forum Device in Poll Mode MAY 
support an NFC Forum Device in Listen 
Mode not indicating conformity to 

[ISO/TEC 14443]. 


Protocol Type bits b3,b2 define the minimum value of TR2 supported by the NFC Forum Device 
in Listen Mode, as specified in Table 31. 


Table 31: Minimum TR2 Coding 


b3 b2 Meaning 
1792/fc (10 etu + 32/fs) 


3328/fc (10 etu + 128/fs) 


5376/fc (10 etu + 256/fs) 


kä lä o] CH 
eOe] CH 


9472/fc (10 etu + 512/fs) 
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Requirements 57: Minimum TR2 Coding 


Poll Mode Listen Mode 

5.6.2.14 The NFC Forum Device MUST 5.6.2.15 In response to a SENSB_REQ 
disregard any value returned in and ALLB REQ with b6 of 
bits b3 and b2 in response to a PARAM set to Ob, the NFC 
SENSB REQ and ALLB_ REQ Forum Device MUST set bits 
with b6 of PARAM set to Ob. In b3,b2 equal to 00b. 
this case, the NFC Forum Device The NFC Forum Device MAY set b3 and b2 
MUST always use " different from 00b in response to a 
TR2wmperauLr as minimum SENSB REQ and ALLB_REQ with b6 of 


TR2. Refer to Appendix A.2 for PARAM set to 1b. 
the value of TR2win,DEFAULT- 

The NFC Forum Device MUST 

use the minimum TR2 value 

defined by b3 and b2 in response 

to a SENSB_REQ and 

ALLB_REQ with b6 of PARAM 

set to 1b. 


Requirements 58: Poll Mode Handling of RFU Value of b4 of Protocol_Type 
Poll Mode 


5.6.2.16 The NFC Forum Device in Poll Mode MUST not continue communicating with 
an NFC Forum Device in Listen Mode that sets b4 to 1b. 


e FWI- Frame Waiting Time Integer (4 bits) 


The FWI codes an integer value used to define the Frame Waiting Time (FWT). The FWT is 
the maximum time an NFC Forum Device in Listen Mode is allowed to wait before sending 
the Listen Frame after the end of a Poll Frame. The FWT is calculated as specified in 
Section 5.9.1. FWI has a value in the range from 1 to 14. The value 15 is RFU. 


Requirements 59: Maximum Value of FWI 


Poll Mode Listen Mode 

5.6.2.17 The NFC Forum Device in Poll 5.6.2.18 The NFC Forum Device MUST 
Mode MUST support an FWI set FWI less than or equal to 
less than or equal to FW ax. FWlyax. Refer to Appendix A.2 


for the value of FWlyax. 


Requirements 60: Poll Mode Handling of RFU Value of FWI 
Poll Mode 


5.6.2.19 The NFC Forum Device MUST treat a received value of FWI = 15 as FWI = 4. 


NFC Digital Protocol Page 60 


NFC-B Technology 


e ADC 


The ADC represents the Application Data Coding supported by the NFC Forum Device in 
Listen Mode and is coded as specified in Table 32. 


Table 32: ADC Coding 


b4 b3 Meaning 


x Ob: Advanced protocol features not supported 
1b: Advanced protocol features supported 


x Ob: Application is proprietary 
1b: Application is coded as described in Table 26. 


e FO 


Table 33 and Table 34 indicate the Frame Options (FO) supported by the NFC Forum Device 
in Listen Mode. FO indicates support for NAD and DID. 


Table 33: FO - NAD 


b2 Meaning 
x NAD supported, if bit is set to 1b. 
Requirements 61: NAD 
Poll Mode Listen Mode 
5.6.2.20 | The NFC Forum Device MUST  5.6.2[.21 The NFC Forum Device MUST 
not use NAD and MUST not support NAD and MUST set 
disregard any value returned by b2 equal to Ob. 
the NFC Forum Device in Listen 
Mode in b2. 


Table 34: FO - DID 


b1 Meaning 
x Supports DID, if bit is set to 1b. 


e SFGI — Start-up Frame Guard Time Integer (4 bits) 


The most significant nibble b8 to b5 of the optional Byte 4 contains SFGI and is used by the 
NFC Forum Device in Listen Mode to define the SFGT. Refer to Section 5.9.2 for the 
definition of SFGT. SFGI has a value in the range from 1 to 14. The value 15 is RFU. The 
default value of SFGI is 0. 
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Requirements 62: SFGI 


Poll Mode Listen Mode 

5.6.2.22 The NFC Forum Device in Poll 5.6.2.23 The NFC Forum Device MUST 
Mode MUST support an SFGI set SFGI less than or equal to 
less than or equal to SFGI max. SFGl max. Refer to Appendix A.2 


for the value of SFGl ax. 


Requirements 63: Poll Mode Handling of RFU Value of SFGI 
Poll Mode 


5.6.2.4 A received value of SFGI = 15 MUST be treated by the NFC Forum Device as 
SFGI = 0. 


5.7 SLOT MARKER 


The SLOT MARKER Command is used by an NFC Forum Device in Poll Mode during collision 
resolution to define the start of the Response time slot for an NFC Forum Device in Listen Mode. 


NOTE Implementation of the SLOT MARKER Command is optional. 


5.7.1 SLOT MARKER Command 
Table 35 defines the format of the SLOT MARKER Command. 


Table 35: SLOT MARKER Command Format 


Byte 1 
APn 


The Anticollision Prefix byte (APn) is formatted as follows: 
b4-b1 are set to 0101b. 
b8-b5 code the slot number, as specified in Table 36. 


Table 36: Coding of Slot Number 


b8 b7 b6 b5 Meaning 
Not allowed 
Slot number 2 


Slot number 3 


e| Oj] ll oO 


Slot number 4 


1 1 1 0 Slot number 15 
1 1 1 1 Slot number 16 
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5.7.2 | SLOT MARKER Response 

The Response to the SLOT MARKER Command is the SENSB_RES Response, as specified in 
Section 5.6.2. 

5.8 SLPB REQ 

The SLPB REQ Command is used to set an NFC Forum Device in Listen Mode, identified by its 
NFCIDO, to the SLEEP state. Refer to [ACTIVITY] for the NFC Forum Device state machine. 
5.8.1 SLPB REQ Command 

Table 37 defines the format of the SLPB. REQ Command. 


Table 37: Format of the SLPB REQ Command 
Byte 1 Byte2-5 
50h NFCIDO 


5.8.2  SLPB RES Response 
Table 38 defines the format of the SLPB. RES Response. 


Table 38: SLPB RES Response Format 
Byte 1 
00h 


5.9 Timing Requirements 


This section specifies the requirements for the different Frame Delay Times for NFC-B 
Technology. The Frame Delay Time (FDT) is the time between two frames transmitted in 
opposite directions. 


5.9.1 Frame Delay Time Pol Listen 


The Frame Delay Time Poll—Listen (FDTs, sre) is the time between a Poll Frame and a Listen 
Frame, as illustrated in Figure 13. The time between the minimum value FDTs, isreN,uiN and the 
maximum value FDTs, isrew,vax defines the time interval in which a Listen Frame is allowed to 
be sent by an NFC Forum Device in Listen Mode in response to a Poll Frame of an NFC Forum 
Device in Poll Mode. 
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FDTsg, isrEN,MiN is the minimum time an NFC Forum Device in Listen Mode has to wait before 
sending the Listen Frame after the end of a Poll Frame. FDTp.visten,min is defined: 


FDTgustenmin = TROmnt+TR1min 


Requirements 64: FDTsa, srENMIN 


Poll Mode Listen Mode 

5.9.1.1 The NFC Forum Device MUST be 5.9.1.2 Following the EoS of a Poll Frame, 
ready to receive the SoS of a Listen the NFC Forum Device MUST wait 
Frame no later than FDTg, isrEN MIN at least FDTsg, i isrEN,uiN (as defined 
after the EoS of a Poll Frame. by TROmn + TRImin) before 


sending the SoS of its Listen Frame. 


Refer to Appendix A.2 for the 
values of TROmin and TR1 win. 


FDT 3, visten,max is the maximum time an NFC Forum Device in Listen Mode is allowed to wait 
before sending the Listen Frame after the end of a Poll Frame. This parameter is also called 
Frame Waiting Time (FWT). The FWT is calculated by the following formula: 


FWT = (256 x 16/fc) x 2^"! 


where, by definition, the integer value of FWI can have a maximum range from 0 to 14. In the 
SENSB RES Response, the NFC Forum Device in Listen Mode informs the NFC Forum Device 
in Poll Mode of the FWI value. Refer to Section 5.6.2 for the SENSB. RES Response format. 
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Requirements 65: Frame Waiting Time 


Poll Mode 


5.9.1.3 The NFC Forum Device MUST 
wait at least FWT + AFWT for the 
SoS of a Listen Frame after the EoS 
of a Poll Frame (except for 
ALLB REQ and SENSB. REQ). 
If the NFC Forum Device does not 
receive the SoS of a Listen Frame 
within FWT + AFWT + ATpo -, 
then the NFC Forum Device MUST 
treat this as a Timeout Error (i.e., 
FDTe,uısten,max equals FWT + 
AFWT + ATpoit): 


Refer to Appendix A.2 for the 
values of ATpoi, and AFWT. 


Between FWT + AFWT and FWT + AFWT + 
AT pot, the NFC Forum Device MAY accept the 
SoS of a Listen Frame or MAY generate a 
Timeout Error. 


Listen Mode 


5.9.1.4 


Following the EoS of a Poll Frame, 
the NFC Forum Device MUST wait 
no longer than FWT before sending 
the SoS of its Listen Frame (except 
for ALLB. REQ and SENSB REQ; 
].e., FDT 3, isrEN,MAX equals FWT). 


5.9.1.5 In the case of the ALLB_ REQ, 
SENSB_REQ, and 
SLOT_MARKER Commands, the 
NEC Forum Device MUST wait 
FWTsensp for the SoS of the Listen 
Frame after the EoS of the Poll 
Frame. 
If the NFC Forum Device does not 
receive the SoS of the Listen Frame 
within FWTsenss + ATpo tt, then 
the NFC Forum Device MUST treat 
this as a Timeout Error (i.e., 
FDTsg, isrEN MAX equals FWrTSszuss + 
ATpouL). 


Refer to Appendix A.2 for the 
values of FWT sensg and ATpou . 


Between FWT sense and FWT sense + AT poi, 
the NFC Forum Device MAY accept the SoS of 
a Listen Frame or MAY generate a Timeout 
Error. 


5.9.1.6 


In the case of the ALLB. REQ, 
SENSB REQ, and 

SLOT MARKER Commands, 
following the EoS of the Poll 
Frame, the NFC Forum Device 
MUST wait no longer than 
FWTsenss before sending the SoS 
of the Listen Frame (i.e., 

FDTa, isrEN MAX equals FWTsenss. 


Refer to Appendix A.2 for the 
values of FWT senses. 


The NFC Forum Device in Listen Mode is not allowed to produce any detectable disturbance 
during a minimum time period tnn,min before sending a Response. 
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Listen Frame = 180° No subcarrier subcarrier 
| » > 
Hd SoS | 
(b) TRO < TROym + tnn 
Figure 18: tnn min for NFC-B 
Requirements 66: tan min - NFC-B 
Listen Mode 


5.9.1.7 The NFC Forum Device MUST not produce any detectable disturbance during a time 
period of at least thn,min, defined as the minimum of TRO — TROwn and Lon, before 
sending a Response. thn,min MUST be measured before the start of TR1, as shown in 
Figure 18. For TROwn, the Poll Mode value MUST be used. Refer to Appendix A.2 for 
the value of tnn. 


The exact quantity of what constitutes ‘any detectable disturbance’ is not defined by this version of 
the specification. 


5.9.2 Frame Delay Time Listen—Poll 


The Frame Delay Time Listen Poll (FDTag poi) is the time between a Listen Frame and a Poll 
Frame, as shown in Figure 13. The minimum value FDTg poi i,u defines the time an NFC 
Forum Device in Poll Mode has to wait before sending a new Poll Frame after receipt of a Listen 
Frame. A maximum value FDTa poii max is not defined. FDTg poi |, uw is defined: 


FDTsag rot wm = TR2min 


TR2yn is the minimum value of TR2, as shown in Figure 13. The value of TR2in, supported by 
the NFC Forum Device in Listen Mode, is indicated in the Protocol Type of the SENSB. RES 
Response as specified in Table 31 in Section 5.6. 
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Requirements 67: FDT; Got min 


Poll Mode Listen Mode 

5.9.2.1 Following the end of a Listen Frame, 5.9.2.2 The NFC Forum Device MUST be 
the NFC Forum Device MUST wait ready to receive the SoS of a new 
at least for FDTe sot wm before Command no later than 
transmitting the SoS of a new FDTsg poii. after the end of a 
Command. Listen Frame. 


If the SoS of a new Command is received before 
FD sot tum, then the NFC Forum Device MAY 
treat this as a Transmission Error. 


A specific value for FDTg poii, is defined after the ATTRIB Response. The SFGT is the 
minimum time the NFC Forum Device in Poll Mode, configured for reading Type 4B Tag 
platform, is waiting before the (NFC Forum Device in Listen Mode, configured for emulating) 
Type 4B Tag platform is ready to receive the next frame after it has sent the ATTRIB Response. 


The SFGT is calculated by the following formula: 
SFGT = (256 x 16/fc) x 25°" 


where SFGI has a range from 1 to 14 and is returned by the NFC Forum Device in Listen Mode 
in the in the SENSB. RES Response. Refer to Section 5.6.2 for the definition of the SENSB. RES 
Response. If the NFC Forum Device in Listen Mode returns SFGI equal to zero or SFGI is not 
returned, then no SFGT is needed and FDTg,poit,min applies. 
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5.9.2.3 


5.9.2.5 


Requirements 68 


If the NFC Forum Device in Listen 
Mode returns an SFGI different 
from zero, the NFC Forum Device 
in Poll Mode MUST wait at least 
SFGT+ASFGT before sending the 
next frame after the NFC Forum 
Device in Listen Mode has sent the 
ATTRIB Response. Refer to 
Appendix A.2 for the value of 
ASFGT. 


If the NFC Forum Device in Listen 
Mode returns an SFGI equal to zero 
or SFGI is not returned, the NFC 
Forum Device in Poll Mode MUST 
wait at least FDTg poii, uiv before 
sending the next frame after the 
NFC Forum Device in Listen Mode 
has sent the ATTRIB Response. 


NFC-B Technology 


: SFGT - NFC-B 


Listen Mode 


5.9.2.4 


If the NFC Forum Device returns an 
SFGI other than zero, then the NFC 
Forum Device MUST be ready to 
receive the start of a new Poll 
Frame no later than SFGT after the 
end of the ATTRIB Response 
frame. 


If the start of a new Poll Frame is received 
before SFGT, then the NFC Forum Device MAY 
treat this as a Transmission Error. 


5.9.2.6 


If the NFC Forum Device returns an 
SFGI equal to zero or does not 
return an SFGI, then the NFC 
Forum Device MUST be ready to 
receive the start of a new Poll 
Frame no later than FDTs,poit,min 
after the end of the ATTRIB 
Response frame. 


If the start of a new Poll Frame is received 
before FDTg com, then the NFC Forum 
Device MAY treat this as a Transmission Error. 


A specific value for FDTg poii, is defined for the re-activation of the NFC Forum Device in 
Listen Mode following an S(DESELECT) Response (see Section 13.2.7). 


Poll Mode 


5.9.2.7 


Requirements 69: FDTag reactivation 


Following the end of an 
S(DESELECT) Response, the NFC 
Forum Device MUST wait at least 
FDTgracrivarioN before 
transmitting the start of a new Poll 
Frame. 


Refer to Appendix A.2 for the value 
of FDTs Reactivation. 


5.9.3 Guard Time 


This section specifies the guard time of an Unmodulated Carrier, after which the NFC Forum 
Device in Listen Mode must be ready to receive an ALLB_REQ or SENSB_REQ Command. 


NFC Digital Protocol 


Listen Mode 


5.9.2.8 


The NFC Forum Device MUST be 
ready to receive the start of a new 

Poll Frame no later than 

FDTB, REACTIVATION after the end of 
an S(DESELECT) Response. 


If the start of a new Poll Frame is received 
before FDTg reactivation, then the NFC Forum 
Device MAY treat this as a Transmission Error. 
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Requirements 70: Guard Time - NFC-B 
Listen Mode 


5.9.3.1 When an NFC Forum Device in Listen Mode is exposed to an Unmodulated Carrier 
(see [ANALOG]), it MUST be ready to receive an ALLB_REQ or SENSB REQ 
Command within a guard time GTg. Refer to Appendix A.2 for the value of GTg. 
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6 NFC-F Technology 


This section specifies NFC-F Technology-related features of the NFC Forum Device. Contents, 
when already defined elsewhere, have been included for readability reasons. 


If not explicitly stated otherwise, [ISO/IEC 18092] is normative reference for this section. 
Deviations from and restrictions of [ISO/TEC. 18092] are indicated within the text on the topics 
for which deviations and restrictions apply. 


6.1 Sequence Format 


This section describes the sequence format for NFC-F Technology. 


6.1.1 Modulation 


In both transmission directions, the analog signal is modulated using Manchester coding with 
ASK modulation. For details about the Modulation Index refer to [ANALOG]. Figure 19 
illustrates Manchester coding. 


V pattern E pattern D pattern E pattern E pattern E 


100 % 
T | I | WN WN 
MINI ETAT ATU 
| | | TUNI 
| | | TI | TI Ii | 
ii Ill (III Ill | I | | 
|| | | wi Wu ill | | I 


Figure 19: Manchester Coding with ASK Modulation 


- 100 % 
1 bd 


The modulation principle of ASK is used to modulate the carrier amplitude in a defined way 
between a V3 and a V4. The carrier signal not modulated is denoted as V3, the modulated carrier 
signal is denoted as V4. Refer to [ANALOG] for the definition of V3 and V4. 


Manchester coding uses this principle to define two particular patterns: E and D. 
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Requirements 71: Creation of Signal Patterns - NFC-F 
Poll and Listen Mode 


6.1.1.1 The NFC Forum Device MUST build signal patterns E and D: 


e Pattern E: at the beginning of the bit duration, a V3 MUST occur for a time of half 
the bit duration (no carrier modulation). After a time of half the bit duration, a 
transition to V4 MUST occur and the V4 MUST last for a time of half the bit 
duration. 


e Pattern D: at the beginning of the bit duration, a Vj MUST occur for a time of half 
the bit duration. After a time of half the bit duration, a transition to V MUST occur 
and the V; MUST last for a time of half the bit duration (no carrier modulation). 


Requirements 72: Reading of Signal Patterns - NFC-F 
Poll and Listen Mode 


6.1.1.2 The NFC Forum Device MUST read signal patterns E and D as follows: 


e If the NFC Forum Device detects a V3 at the beginning of the bit duration that lasts 
for half the bit duration, followed by a transition to V4 with the V4 lasting for half 
the bit duration, the NFC Forum Device MUST read this as pattern E. 


e Ifthe NFC Forum Device detects a V4 at the beginning of the bit duration that lasts 
for half the bit duration, followed by a transition to V3 with the V3 lasting for half 
the bit duration, the NFC Forum Device MUST read this as pattern D. 


e All other patterns MUST be treated as invalid patterns. 


Requirements 73: NFC-F Transition Boundaries 
Poll and Listen Mode 


6.1.1.3 For both of PollListen communication and Listen—>Poll communication, the 
transition boundaries MUST occur between + 4/fc in the Operating Field. 


NOTE Requirements in Section 6.1.1 overrule deviating definitions in [ISO/IEC_18092]. 


6.1.2 Synchronization 


Figure 20 illustrates the different parameters used for NFC-F Technology signal synchronization 
and related signal timing parameters. Depending on the coupling between the NFC Forum Device 
in Poll Mode and the NFC Forum Device in Listen Mode, the waveform looks different. The 
coupling may inverse the waveform, called reverse polarity. 
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a) Obverse Polarity 
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Figure 20: Signal Synchronization and Timing Parameters 


For the demodulator, the beginning of a signal is indicated by the SoS. The duration of the SoS is 
TR1 and has a value of 48 bd. 


Requirements 74: Synchronization - NFC-F Sequence 


Poll and Listen Mode 


6.1.2.1 The NFC Forum Device MUST code SoS as a series of 48 patterns D. 


6.1.2.2 The NFC Forum Device MUST be synchronized no later than 48 patterns D or E. 
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6.1.3 De-synchronization 


The end of a signal is indicated by no longer modulating the carrier. 


Requirements 75: De-synchronization - NFC-F 


Poll and Listen Mode 


The NFC Forum Device MAY indicate the EoS by not modulating the carrier for a time longer than 
one bit duration. 


6.1.3.1 For de-synchronization, the NFC Forum Device MUST use the SoD as specified in 
Section 6.4 or the EoS. 
e If the SoD is used, the following applies: 
The NFC Forum Device MUST stop demodulating after receipt of the EoD, as 
indicated by the SoD containing the LEN byte (see Section 6.4). 
e If the EoS is used, the following applies: 


When directly following a pattern E or D, the NFC Forum Device MUST treat a 
carrier not modulated for a time longer than one bit duration as the EoS and stop 
demodulating. 


6.2 Bit Level Coding 
The patterns E and D are used to code the digital alphabet Logic *0" and Logic “1”. 
Requirements 76: Bit Level Coding - NFC-F 
Poll and Listen Mode 


6.2.1.1 The NFC Forum Device MUST code Logic “0” and Logic “1” as follows: 
e Logic “1”: pattern E 
e Logic “0”: pattern D 


Requirements 77: Bit Level Decoding - NFC-F 
Poll and Listen Mode 


6.2.1.2 The NFC Forum Device MUST decode Logic “0” and Logic “1” as follows: 
e Ifthe NFC Forum Device detects pattern E, then it MUST decode this as Logic “1”. 
e Ifthe NFC Forum Device detects pattern D, then it MUST decode this as Logic “0”. 


Invalid patterns MAY be treated as Transmission Errors, or the device MAY use implementation 
dependent methods to decode an invalid pattern into a Logic “0” or Logic “1”. 


6.3 Frame Format 


This section defines the frames and characters of the NFC Forum Device configured for NFC-F 
Technology. 
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A character consists of 8 data bits without start, stop, and parity bits, as shown in Figure 21. 
Characters are transmitted as a continuous string, with no separation in time between characters. 


msb lsb 
b8 b7 |bG6 "bb "bd |b3 |b2 bl 


Figure 21: NFC-F - Character Format 


A frame starts with the SoF followed by the data, as illustrated in Figure 22. Data consists of 
characters. 


SoF Data (consisting of Characters) 


Figure 22: NFC-F - Frame Format 


Requirements 78: NFC-F - Frame Format 
Poll and Listen Mode 


6.3.1.1 A frame MUST begin with an SoF, followed by characters according to Figure 21. 


6.3.1.2 The NFC Forum Device MUST code SoF as B24Dh. 


6.3.1.3 After the synchronization, the NFC Forum Device MUST decode a series of Logic “0”s 
and Logic *1"s with a value B24Dh or 4DB2h as SoF. 


If the NFC Forum Device receives 4DB2h, then all subsequent bits MUST be inverted 
(i.e., a Logic “0” becomes Logic “1” and Logic “1” becomes Logic “0”). 
The NFC Forum Device MAY decide the polarity to be used based on a subset of the SoF. 


6.4 Data and Payload Format 


Data transmitted in an NFC-F frame has the following substructure. They consist of an SoD, the 
payload, and an EoD. 


The SoD contains a length byte LEN, indicating the length of the payload + 1. 
The payload consists of the Commands and Responses, as described in Section 6.5. 


The EoD contains a two-byte checksum, referred to as CRC_F. The CRC F is a function of k 
data bits. The number of bits k is a multiple of eight. Input for CRC F calculation is the SoD and 
the payload. 


The NFC-F data and payload format is illustrated in Figure 23. 


Data 
SoD Payload EoD 
LEN Byte 1 Byte 2 ies Byten | CRC F1| CRC F2 


Figure 23: Data and Payload Format - NFC-F 
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Requirements 79: Data and Payload Format - NFC-F 
Poll and Listen Mode 


6.4.1.1 Data MUST be transmitted in frames using the frame format as defined in 
Section 6.3. 


6.4.1.2 The SoD MUST contain a length byte LEN at the position shown in Figure 23 with 
a value equal to n+1, where n indicates the number of bytes that the payload 
consists of. 


6.4.1.3 The SoD MUST have a value between 1 and 254. The NFC Forum Device MUST 
treat other values as a Transmission Error. 


6.4.1.4 The payload MUST follow the SoD as indicated in Figure 23. 


6.4.1.5 The payload MUST be followed by an EoD at the position, as indicated in 
Figure 23. 


6.4.1.6 The EoD MUST contain a CRC F. 


6.4.1.7 The CRC_F MUST be calculated as defined in [ISO/IEC 18092]. CRC F1 is the 
MSB and CRC F2 is the LSB. 


6.4.1.8 The NFC Forum Device MUST verify a CRC F on receipt, as defined in 
[ISO/IEC 18092], and MUST treat failure of verification as a Transmission Error. 


NOTE Requirement 6.4.1.3 overrules [ISO/IEC 18092]. 


6.5 Command Set 


Payload exchanged between NFC Forum Devices consists of Commands and Responses. 
Table 39 lists the Commands that are available to the NFC Forum Device configured for NFC-F 
Technology. For each Command, the corresponding Response is indicated. 


Table 39: NFC-F - Command Set 


Poll Mode (Command) Listen Mode (Response) 
SENSF_REQ SENSF_RES 


NOTE The Command and Response listed in Table 39 have different names in 
[ISO/TEC 18092]: SENSF_REQ refers to Polling Request and SENSF_RES refers 
to Polling Response. 


6.6 SENSF REQ 


The SENSF_REQ Command is used by an NFC Forum Device in Poll Mode to probe the 
Operating Field for NFC Forum Devices in Listen Mode. 


6.6.1 SENSF REQ Command 
Table 40 defines the format of the SENSF_REQ Command. 
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Table 40: SENSF REQ Command Format 


Byte 1 Byte2-3 Byte 4 Byte 5 
00h SC RC TSN 
The components of this Command are defined as follows: 


SC 


The System Code (SC) contains information regarding the NFC Forum Device to be polled for 


(e.g., the Technology Subset). 


Requirements 80: System Code (SC) 


Poll Mode Listen Mode 


6.6.1.1 If configured to poll for any NFC — 6.6.1.2 
Forum Device in Listen Mode, 
the NFC Forum Device MUST 
set SC to FFFFh. 


The NFC Forum Device MAY set SC to a 
different value if configured to poll for NFC 
Forum Devices in a specific configuration. 


The NFC Forum Device MUST 
be ready to receive a 

SENSF REQ Command with SC 
equal to FFFFh. 


When configured for the Tag 
Type 3 platform, the NFC Forum 
Device MUST accept at least one 
different value for SC in 
accordance to the requirements 
given in [JS X 6319-4] for SC. 
The NFC Forum Device MUST 
not send the SENSF RES 
Response in all other cases. 


RC 


The Request Code (RC) is used to retrieve additional information in the SENSF. RES Response 


and Table 41 specifies the RC code. 


Table 41: Coding of RC 


Value Meaning 

00h No System Code information requested 
01h System Code information requested 
02h Advanced protocol features supported 


Other values RFU 
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Requirements 81: Request Code (RC) 


Poll Mode Listen Mode 

6.6.1.3 If configured to poll for NFC 6.6.1.4 If configured for NFC-DEP 
Forum Devices that are Protocol, the NFC Forum Device 
configured for the NFC-DEP MUST be ready to receive a 
Protocol, the NFC Forum Device SENSF REQ Command with RC 
MUST set RC to 00h. set to 00h or 02h. 
If configured to poll for NFC If configured for Type 3 Tag 
Forum Devices that are platform, the NFC Forum Device 
configured for the Type 3 Tag MUST be ready to receive a 
Platform, the NFC Forum Device SENSF REQ Command with RC 
MUST set RC to 00h or 01h. set to 00h, O1h, or 02h. 


The NFC Forum Device MUST 
treat a SENSF REQ Command 
with RC different from 00h, 01h, 
and 02h as RC equal to 00h. 


NOTE Advanced protocol features are not used by this version of the specification. 
NOTE Support for Type 3 Tag platform Listen Mode is optional. 
TSN 


The Time Slot Number (TSN) is used for collision resolution and to reduce the probability of 
collisions. The anticollision scheme is based on the definition of time slots in which NFC Forum 
Devices in Listen Mode are invited to respond with minimum identification data. 


The NFC Forum Device in Poll Mode sends a SENSF_REQ Command with a TSN value 
indicating the number of time slots available. Each NFC Forum Device in Listen Mode presents 
within the range of the Operating Field, and then randomly selects a time slot in which it 
responds. The TSN byte set to 00h forces all NFC Forum Devices in Listen Mode to respond in 
the first time slot, and therefore, this TSN value is used if collision resolution is not used. 


Figure 24 shows an example for the collision resolution mechanism. The NFC Forum Device in 
Poll Mode (Device 0) receives answers from four NFC Forum Devices in Listen Mode. Device 0 
can distinguish Device 4 and Device 2 because they responded in different time slots. The 
Responses from Device 1 and Device 3 cannot be distinguished because a collision occurred in 
time slot 1. Time slots are numbered sequentially, starting from 0. 
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Time slot 0 Time slot 1 Time slot 2 Time slot 3 
time > € Toevay > | € Trimestot > € Trimestot > € Trimestot > | € Trimestot > 
SENSF_REQ SENSF_RES SENSF_RES SENSF_RES 
device 0 device 4 device 1 device 2 
SENSF_RES 
device 3 
Figure 24: Collision Resolution (Example) 
Table 42 specifies the coding of the TSN byte. 
Table 42: Coding of TSN 
TSN 00h 01h 03h 07h OFh All 
other 
value 
s 
Number of 1 2 4 8 16 RFU 
Time Slots 
Time Slots Time slotO TimeslotO TimeslotO Time slot0 Time slot 0 
allowed for Time slot 1 E. " 
SENDEORES Timeslot 3 Time slot7 Time slot 15 
Response 
Requirements 82: Time Slot Number (TSN) 
Poll Mode Listen Mode 
6.6.1.5 The NFC Forum Device MUST 6.6.1.6 The NFC Forum Device MUST 
set the TSN byte as specified in be ready to receive a 
Table 42. SENSF REQ Command with a 
TSN byte set to a value as 
specified in Table 42. 
6.6.1.7 The NFC Forum Device MUST 6.6.1.8 The NFC Forum Device MUST 
be ready to receive SENSF RES randomly select a time slot 
Responses in each allowed time allowed according to Table 42, 
slot, according to Table 42. and send its SENSF. RES 
Response in the selected time slot. 
6.6.2  SENSF RES Response 


Table 43 defines the SENSF. RES format. 
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Table 43: SENSF RES Format 


Byte 1 Byte2-9 Byte10-11 Byte12-14 Byte 15 Byte 16 Byte 17 [Byte 18-19] 
01h | NFCID2 PADO PAD1 MRTlcueck MRTluppate PAD2 [RD] 
NFCID2 


NFCID2 is the NFC Forum Device identifier. Table 44 shows the NFCID2 format. 


Table 44: NFCID2 Format 


Byte 1 Byte 2 Description 


01h FEh NFC-DEP Protocol supported. 
Bytes 3 to 8 are randomly generated. 


02h FEh Tag Type 3 platform supported. 
Bytes 3 to 8 are randomly generated. 


All other values Tag Type 3 platform supported. 
Bytes 1 to 8 are proprietary. 


Requirements 83: NFCID2 in SENSF RES 


Listen Mode 


6.6.2.1 The NFCID2 MUST be coded as specified in Table 44. 


PADO 


NFC Forum Devices do not use PADO for information exchange. 


Requirements 84: PADO 


Poll Mode Listen Mode 

6.6.2.2 The NFC Forum Device MUST 6.6.2.3 The NFC Forum Device MUST 
be ready to receive a PADO field set PADO to FFh FFh. 
coded as any value. The NFC Forum Device MAY set PADO to a 


different value if configured for Type 3 Tag 
platform in a specific configuration. 


PAD1 


The PAD1 format depends on the NFC-F Technology Subset for which the NFC Forum Device 
in Listen Mode is configured. NFC Forum Devices configured for the NFC-DEP Protocol do not 


use PAD1. 
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Requirements 85: PAD1 


Poll Mode Listen Mode 
6.6.2.4 If configured to poll for NFC The NFC Forum Device MAY set PAD1 to any 
Forum Devices that are only value. 


configured for the NFC-DEP 
Protocol, the NFC Forum Device 
MUST disregard any value 
returned in the PAD1 field. 


If configured to poll for NFC 
Forum Devices that are 
configured for the Type 3 Tag 
platform, the NFC Forum Device 
MUST be ready to receive a 
PAD! field coded as any value. 


NOTE Support for Type 3 Tag platform Listen Mode is optional. 


MRTIcugck 


Coding of MRTIcugck depends on the NFC-F Technology Subset for which the NFC Forum 
Device in Listen Mode is configured. NFC Forum Devices configured for the NFC-DEP Protocol 
do not use MRTIcuecx: 


Requirements 86: MRTIcHeck 


Poll Mode Listen Mode 

6.6.2.5 If configured to poll for only 6.6.2.6 If configured for Type 3 Tag 
NFC Forum Devices that are platform, the NFC Forum Device 
configured for the NFC-DEP MUST set MRTlcueck as specified 
Protocol, the NFC Forum Device in Section 10.6. 
MUST disregard any value If configured for the NFC-DEP Protocol, the 
returned in the MRTlcueck field. NEC Forum Device MAY set MRTI cuecx to 
If configured to poll for NFC any value. 


Forum Devices that are 
configured for the Type 3 Tag 
platform, the NFC Forum Device 
MUST be ready to receive an 
MRTIcneck value as specified in 
Section 10.6. 


MRTluppate 


The MRTluppate format depends on the NFC-F Technology Subset for which the NFC Forum 
Device in Listen Mode is configured. NFC Forum Devices configured for the NFC-DEP Protocol 
do not use MRTluppate- 


NFC Digital Protocol Page 80 


NFC-F Technology 


Requirements 87: MRTlyppate 


Poll Mode Listen Mode 

6.6.2.7 If configured to poll for the 6.6.2.8 If configured for the Type 3 Tag 
NFC-DEP Protocol, the NFC platform, the NFC Forum Device 
Forum Device MUST disregard MUST set MRTluppate as 
any value returned in the specified in Section 10.6. 
MRTluppare field. If configured for the NFC-DEP Protocol, the 
If configured to poll for Type 3 NFC Forum Device MAY set MRTluppate to 
Tag platform, the NFC Forum any value. 
Device MUST be ready to 


receive an MRTluppate value as 
specified in Section 10.6. 


PAD2 


The PAD2 format depends on the NFC-F Technology Subset for which the NFC Forum Device 
in Listen Mode is configured. NFC Forum Devices configured for the NFC-DEP Protocol do not 
use PAD2. 


Requirements 88: PAD2 


Poll Mode Listen Mode 
6.6.2.9 If configured to poll for NFC- The NFC Forum Device MAY set PAD2 to any 


DEP Protocol, the NFC Forum value. 
Device MUST disregard any 
value returned in the PAD? field. 


If configured to poll for Type 3 
Tag platform, the NFC Forum 
Device MUST be ready to 
receive an PAD2 value as any 
value. 


RD 


Request Data (RD) is included in the SENSF RES Response if requested in the RC field of the 
SENSF REQ Command. The Request Data (RD) format depends on the NFC-F Technology 
Subset for which the NFC Forum Device in Listen Mode is configured. 
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6.6.2.12 


b8 
0 0 
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Requirements 89: Request Data (RD) 


If the preceding SENSF_REQ 
Command contained an RC byte 
set to 00h, the NFC Forum 
Device MUST treat the presence 
of the RD field in the 

DENGE RES Response as 
Protocol Error. 


If configured to poll for Type 3 
Tag platform and if the 
preceding SENSF REQ 
Command contained an RC byte 
set to O1h, the NFC Forum 
Device MUST be ready to 
receive an RD value of 2 bytes 
length in the SENSF RES 
Response. 


If the preceding SENSF_REQ 
Command contained an RC byte 
set to 02h, the NFC Forum 
Device MUST be ready to 
receive an RD value 2 bytes long 
inthe SENSF RES Response. 


If the preceding SENSF_REQ 
Command contained an RC byte 
set to 01h or 02h, the NFC 
Forum Device MUST accept a 
SENSF RES without RD bytes 
as a valid response. 


Listen Mode 


6.6.2.11 


If the preceding SENSF_REQ 
Command contained an RC byte set 
to 00h, the NFC Forum Device 
MUST not send RD bytes within 
the SENSF RES Response. 


If configured for the Type 3 Tag 
platform and if the preceding 
SENSF REQ Command contained 
an RC byte set to 01h, the NFC 
Forum Device MUST: 


e Set the 2 RD bytes equal to the 
System Code. 


e Send out the RD bytes as part 
of the SENSF. RES Response 
MSB first. 


If the preceding SENSF_REQ 
Command contained an RC byte set 
to 02h, the NFC Forum Device 
MAY send RD bytes shown in 
Table 45 and Table 46 within the 
DENGE RES Response. 


Table 45: RD Format Advanced Protocol Features (Byte 18) 


0 0 0 0 0 0 
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Table 46: RD Format Advanced Protocol Features (Byte 19) 


b8 b7 b6 b5 b4 b3 b2 b1 Meaning 


1 Automatically selectable bit rates 


0 RFU 


0 RFU 


0 RFU 


X Drot use 716 and Dusress Pour = 16 supported, if 
bit is set to 1b. 


B Drot ere =8 and Diisrev Pour = 8 supported, if 
bit is set to 1b. 


X Dpottsusten 74 and Diisres pon = 4 supported, if 
bit is set to 1b. 


X  DeoiLsusreN =2 and Diisrey Pour = 2 supported, if 
bit is set to 1b. 


6.7 Timing Requirements 


This section specifies the requirements for the different Frame Delay Times for NFC-F 
Technology. The Frame Delay Time (FDT) is the time between two frames transmitted in 
opposite directions. 


6.7.1 Frame Delay Time Poll Listen 


The Frame Delay Time Poll—Listen (FDTristen) is the time between the end of the last bit of a 
Poll Frame and the start of the SoF of a Listen Frame as shown in Figure 20. The time between 
the minimum value FDTevisten,min and the maximum value FDTr, usten max defines the time 
interval in which a Listen Frame is allowed to be sent in response to a Poll Frame. 


NOTE The term “Frame Response Time" as used in [ISO/TEC. 18092] is referred to as 
*Frame Delay Time" in this document. 


FDT., LISTEN (except SENSF REQ) 


FDTevisten,min is the minimum time an NFC Forum Device in Listen Mode has to wait before 
sending the Listen Frame after the end of a Poll Frame. 


Except for the SENSF REQ Command, FDTe,isten,min is defined: 
FDTE LISTEN, MIN = TROF isrEN MIN + TR1 


where TR1 is the synchronization time (the bit duration of SoS: 48 bd) as illustrated in Figure 20. 
Refer to Appendix A.3 for the value of TROg,Listen,min- 
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Requirements 90: FDT- isten min (except SENSF_REQ) 


Poll Mode Listen Mode 

6.7.1.1 Except for the SENSF REQ 6.7.1.2 Except for the SENSF_REQ 
Command, the NFC Forum Device Command following the end of a 
MUST be ready to receive the SoF Poll Frame, the NFC Forum 
of a new Listen Frame no later than Device MUST wait at least 
FD isrEN,MIN after the end of a FDTE LISTEN, MIN before sending the 
Poll Frame. SoF of its Listen Frame. 


The NFC Forum Device MAY ignore any 
response before FDTz,isrEN,MiN- 


FDTr, LISTEN,SENSF REQ 


For the SENSF REQ Command, FDTr, isreN,sENsr ppo depends on the time slot the NFC Forum 
Device in Listen Mode is responding in, and is defined: 


FDTr,isreN,sENsr nEQ = TROListen + TRI 
where TR1 is the synchronization time (the bit duration of SoS: 48 bd) as illustrated in Figure 20. 
TRO, isiew is given in the following formula: 

Tpecay + n X Trmestot < TROvsten < Toevay + (n + 1) x Trimestot — 30 x 8 bd 


where n is the time slot number randomly selected by the NFC Forum Device in Listen Mode 
(0 < n € TSN), and 30 x 8 bd is the bit duration of SENSF. RES. Refer to Appendix A.3 for the 
values of Trei ae and TrimeEsLot- 
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Requirements 91: FDTe LISTEN,SENSF_REQ 


Poll Mode Listen Mode 

6.7.1.3 Following the end of a Poll Frame — 6.7.1.4 Following the end of a 
containing the SENSF REQ SENSF REQ Command, the 
Command, the NFC Forum Device NFC Forum Device MUST send 
MUST accept the SoF of the the SoF of the Listen Frame 
Listen Frame containing the containing the SENSF RES 
SENSF RES Response within the Response within one of the time 
time slots defined by slots defined by 
FDTr,isrEN,sENsF REQ- FDT ,uisrEN,sENsF pro, 


If the NFC Forum Device does not 
receive the SoF of the Listen 
Frame containing the SENG RES 
Response within Tee Ay + 
(TSN+1) X TrimESLoT — 30 x 8 bd + 
TR1 + ATpoLL, then the NFC 
Forum Device MUST treat this as 
a Timeout Error. 
Refer to Appendix A.3 for the 
value of ATpoLL.- 
Between TpeLay + (TSN+1) x TrwEsLor — 30x 
8 bd + TR1 and TpeLay F (TSN+1) X TrmesLorT 
— 30 x 8 bd + TR1 + AT pout, the NFC Forum 
Device MAY accept a SENSF_RES Response 
or MAY generate a Timeout Error. 


6.7.2 Frame Delay Time Listen—Poll 


The Frame Delay Time Listen Poll (FDTz pox) is the time between the end of the last bit of a 
Listen Frame and the start of the SoF of a Poll Frame, as shown in Figure 20. In case the Listen 
frame is a SENSF_RES, The Frame Delay Time Listen Poll (FDTf poru) is the time between 
the end of the time slot specified in the SENSF_REQ and the start of the SoF of a Poll Frame. 
The minimum value FDTr poi wm defines the time an NFC Forum Device in Poll Mode has to 
wait before sending a new Poll Frame after receipt of a Listen Frame. A maximum value 
FDTz»poiiuax is not defined. 


FDTrpoiL,MiN is defined: 
FDTceou wm = TROF porL,mn + TR1 


where TR1 is the synchronization time (the bit duration of SoS: 48 bd) as illustrated in Figure 20. 
Refer to Appendix A.3 for the value of TRO¢ poii Mm. 
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NFC-F Technology 


Requirements 92: FDT po, MN 


Except for the SENSF RES, following 6.7.2.2 


the end of a Listen Frame, the NFC 
Forum Device MUST wait at least 
FDT roii before transmitting the 
SoF of a new Poll Frame. 

For the SENSF RES, following the 
end of the time slot specified in the 


SENSF REQ, the NFC Forum Device 


MUST wait at least for a time 
FDT roii, before transmitting the 
SoF of a new Poll Frame. 


Listen Mode 


The NFC Forum Device MUST be 
ready to receive the SoF of a new 
Poll Frame no later than 

FD Gotwm after the Listen 
Frame. 


If the SoF of a Poll Frame is received before 
FDT E. poii, uw, then the NFC Forum Device 
MAY treat this as a Transmission Error. 


A specific value for FDT¢,pott,min is defined for the re-activation of the NFC Forum Device in 
Listen Mode following a DSL. RES Response (see Section 14.9.2) or an RLS. RES Response 
(see Section 14.10.2). 


Poll Mode 


6.7.2.3 


NOTE 


Requirements 93: FDT £ reactivation 


Following the end of a DSL_RES 
Response or a RLS_RES Response, 
the NFC Forum Device MUST wait 
at least for FDTeE Reactivation before 
transmitting the start of a new Poll 
Frame. 

Refer to Appendix A.3 for the value 
of FD Reactivation: 


Listen Mode 


6.7.2.4 


The NFC Forum Device MUST be 
ready to receive the start of a new 
Poll Frame no later than 

FDT; reactivation after the end of a 
DSL_RES Response or a RLS_RES 
Response. 


If the start of a new Poll Frame is received 
before FDT¢ Reactivation, then the NFC Forum 
Device MAY treat this as a Transmission Error. 


Requirement 6.7.2.3 only applies for Initiator and not for Reader/Writer. In 
Reader/Writer mode, re-activation of a Type 3 Tag Platform is done by means of a 


Reset as defined in [ANALOG]. 


Requirement 6.7.2.4 applies for Target and not for Type 3 Tag (emulation). 
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6.7.3 Guard Time 


This section specifies the guard time of an Unmodulated Carrier, after which the NFC Forum 
Device in Listen Mode must be ready to receive a SENSF REQ Command. 


Requirements 94: Guard Time - NFC-F 


Listen Mode 

6.7.3.1 When an NFC Forum Device in Listen Mode is exposed to an Unmodulated Carrier (see 
[ANALOG]), it MUST be ready to receive a SENSF REQ Command within a guard 
time GTr. 


Refer to Appendix A.3 for the value of GTr. 
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duplex Protocols 


Half-duplex Protocols 


For the NFC Forum Devices, data is transmitted using half-duplex protocols. These protocols 
share common characteristics that are described in this section. Specific characteristics of each 
half-duplex protocol such as timeouts and exception handling are described in the following 


sections. 


Half-duplex means that only one device sends data at a time. Specifically for NFC Forum 
Devices, there is a master-slave relationship between two devices. If the NFC Forum Device is in 
Poll Mode, it is the master; if the NFC Forum Device is in Listen Mode, it is the slave. 


The NFC Forum Device in Poll Mode sends a single Poll Frame and then waits for a Listen 
Frame. The NFC Forum Device in Listen Mode waits for a Poll Frame before sending a single 
Listen Frame. 


Requirements 95: General Rules for Half-duplex Transmission Protocol 


Poll Mode 


7.1.1.1 


Listen Mode 


After sending a Poll Frame, the NFC 7.1.1.2 


Forum Device in Poll Mode MUST 


switch to receive mode and wait for a 


Listen Frame before switching back 
to transmit mode. 


After the activation of the NFC 
Forum Device in Listen Mode, the 
NFC Forum Device in Listen Mode 
MUST wait for a Poll Frame. 


7.1.1.3 


The NFC Forum Device in Poll 
Mode MUST not send another Poll 
Frame until it has received a Listen 
Frame or until a timeout occurred 
with no Listen Frame. 


NFC Digital Protocol 


7.1.1.4 


The NFC Forum Device in Listen 
Mode MUST send a Listen Frame 
when it has received a valid Poll 
Frame. After responding, the NFC 
Forum Device in Listen Mode 
MUST return to the receive mode. 
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8 Type 1 Tag Platform 


8.1 Sequence Format 
The Type 1 Tag platform uses the NFC-A synchronization mechanism. 


Requirements 96: Sequence Format - Type 1 Tag Platform 
Poll Mode Listen Mode 


8.1.1.1 Commands and Responses Commands and Responses specified in 
specified in Section 8 (Type 1 Tag Section 8 (Type 1 Tag platform) HAVE TO be 
platform) MUST be transmitted transmitted using NFC-A Technology 
using NFC-A Technology sequences as defined in Section 4.1. 
sequences as defined in 
Section 4.1. 


8.2 Bit Level Coding 
The Type 1 Tag platform uses NFC-A bit level coding. 


Requirements 97: Bit Level Coding - Type 1 Tag Platform 
Poll Mode Listen Mode 


8.2.1.1 Commands and Responses Commands and Responses specified in 
specified in Section 8 (Type 1 Tag Section 8 (Type 1 Tag platform) HAVE TO be 
platform) MUST be transmitted transmitted using NFC-A Technology bit level 


using NFC-A Technology bit- coding as defined in Section 4.2. 
level coding as defined in 
Section 4.2. 


8.3 Frame Format 


The Type 1 Tag platform uses NFC-A frame format for Listen Mode and a specific frame format 
for Poll Mode. 


A Poll Frame consists of the following (see Figure 25): 
e NFC-A SoF 

e 8 data bits, transmitted lsb first 

e EoF 

No parity is added. 


lsb msb 
SoF | b1 b2 b3 b4 b5 b6 b7 b8 EoF 


Figure 25: Frame Format - Type 1 Tag Platform in Poll Mode 
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Requirements 98: Frame Format - Type 1 Tag Platform 


Poll Mode Listen Mode 


8.3.1.1 A Type 1 Tag Poll Frame MUST A Listen Frame HAS TO have the NFC-A 
consist of eight data bits to be standard frame format as defined in Section 4.3. 


transmitted lsb first, MUST begin 
with an SoF, and MUST end with an 
EoF. 


Refer to Section 4.3 for the 
definitions of SoF and EoF. 


8.4 Data and Payload Format 
Type 1 Tag data has the following substructure, and consists of the payload and the EoD. 
The payload consists of the Commands and Responses as described in Section 8.5. 


The Type 1 Tag data and payload format is illustrated in Figure 26. 


Data 
Payload EoD 
Byte 1 Byte 2 m Byten | CRC_B1 | CRC B2 


Figure 26: Data and Payload Format - Type 1 Tag 


The EoD contains a two-byte checksum referred to as CRC. B. Input for CRC_B calculation is 
the payload. 
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Requirements 99: Data and Payload Format - Type 1 Tag 


Poll Mode 


8.4.1.1 The payload MUST be followed 
by an EoD at the position, as 
indicated in Figure 26. The EoD 


MUST contain a CRC B. 


Listen Mode 


The payload HAS TO be followed by an EoD at 
the position, as indicated in Figure 26. The 
EoD HAS TO contain a CRC. B. 


8.4.1.2 The CRC B MUST be calculated The CRC B HAS TO be calculated as defined 
as defined in [ISO/IEC_13239]. in [ISO/IEC_13239]. The initial register 
The initial register content MUST content HAS TO be all ones (FFFFh). 
be all ones (FFFFh). CRC_B1 is CRC_B1 is the LSB and CRC_B2 is the MSB. 
the LSB and CRC B2 is the 
MSB. 

8.4.1.3 The NFC Forum Device MUST The NFC Forum Device HAS TO compare the 
compare the received CRC. B received CRC_B with the CRC. B calculated 
withthe CRC B calculated according to Requirement 8.4.1.2. If different, 
according to Requirement 8.4.1.2. then the NFC Forum Device HAS TO resort to 
If different, then the NFC Forum exception processing with a Transmission 
Device MUST resort to exception Error. 
processing with a Transmission 
Error. 

8.5 Command Set 


Payload exchanged between NFC Forum Devices consists of Commands and Responses. 

Table 47 lists the Commands that are available to the NFC Forum Device in Poll Mode for 
communication with the (NFC Forum Device in Listen Mode configured for emulating the) Type 
1 Tag platform. For each Command, the corresponding Response from the NFC Forum Device in 


Listen Mode is indicated. 


Refer to [T1TOP] for Command coding (except for RID Command/Response) and NFC Type 1 


Tag platform operation. 


Command parameters and names are defined in [T1TOP]. 


NFC Digital Protocol 


Page 91 


Poll Mode (Command) 
RID Command 

RALL Command 
READ Command 
WRITE-E Command 
WRITE-NE Command 
RSEG Command 
READ8 Command 
WRITE-E8 Command 
WRITE-NE8 Command 


Type 1 Tag Platform 


Table 47: Command Set 


Listen Mode (Response) 
RID Response 

RALL Response 

READ Response 
WRITE-E Response 
WRITE-NE Response 
RSEG Response 

READS Response 
WRITE-E8 Response 
WRITE-NE8 Response 


8.6 Read Identifier (RID) 


The RID Command is used to retrieve unique identifier and protocol support capabilities of an 
NFC Forum Device in Listen Mode. 


8.6.1 RID Command 


The format of the RID Command is shown in Table 48. There are no requirements for the ADD, 
DATA, and UID-echo fields other than that they have to be present. 


Table 48: RID Command Format 


Byte 1 Byte 2 Byte 3 Byte4- 7 
78h ADD DATA UID-echo 
Requirements 100: RID Command 
Poll Mode Listen Mode 
8.6.1.1 The NFC Forum Device MUST The NFC Forum Device HAS TO accept each byte 


send each byte of the RID 
Command and the related CRC B 
(i.e., the payload and the EoD) in a 
separate frame. The first frame 
MUST be a short frame as defined 
in Section 4.3, followed by Poll 
Frames according to Requirement 
8.3.1.1. 


The NFC Forum Device does not use the ADD, 
DATA, and UID-echo fields, and MAY set 
these fields to Any Value. 


NFC Digital Protocol 


of the RID Command and the related CRC_B (i.e., 
the payload and the EoD) in a separate frame, 
where the first frame is a short frame as defined 
in Section 4.3, followed by Poll Frames according 
to Requirement 8.3.1.1. 


The NFC Forum Device HAS TO disregard Any 
Value received in the ADD, DATA, and UID-echo 
fields of the RID Command. 
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8.6.2 RID Response 
The format of the RID Response is shown in Table 49. 


Table 49: RID Response Format 
Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 
HRO HR1 UIDO UID1 UID2 UID3 


The UIDO, UID1, UID2, and UID3 bytes contain the unique identifier of the NFC Forum Device 
configured for the Type 1 Tag platform. 


Requirements 101: RID Response 


Poll Mode Listen Mode 


8.6.2.1 The NFC Forum Device MUST be The NFC Forum Device HAS TO indicate 
ready to receive an RID Response NDEF support by setting the most significant 
with the most significant nibble of nibble of HRO to 0001b. 
HRO set to 0001b, indicating Coding of HR1 and of the least significant 
NDEF support. nibble of HRO is out of scope of this 


The NFC Forum Device MUST specification. 
treat an RID Response with the 

most significant nibble of HRO set 

to a value different from 0001b as 

Protocol Error. 


8.6.2.2 The NFC Forum Device MUST be The NFC Forum Device HAS TO return UIDO, 
ready to receive the UIDO, UID1, UID1, UID2, and UID3. The value of UIDO, 
UID2, and UID3 bytes. UID1, UID2, and UID3 is a fixed number or a 
random number. 


8.7 Timing Requirements 


This section specifies the requirements for the different delay times used by the Type 1 Tag 
platform. 


8.7.1 Reader Reader Data Delay 


The Reader-Reader Data Delay (RRDD) is the time between two successive Poll Frames and 
depends on the logic value of the last data bit of the preceding Poll Frame transmitted by the NFC 
Forum Device, as illustrated in Figure 27. 
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RRDD 
» 
ka e Hd 
« 1 bd 1 bd > 1 bd 
Logic "1" transmitted EoF transmitted by SoF transmitted by 
by NFC Forum NFC Forum Device NFC Forum Device 
Device in Poll Mode in Poll Mode in Poll Mode 
(a) Last bit before EoF is Logic "1" 
RRDD 
» 
AU > 
1 bd 1 bd 1 bd 
Logic "0" transmitted EoF transmitted by SoF transmitted by 
by NFC Forum NFC Forum Device NFC Forum Device 
Device in Poll Mode in Poll Mode in Poll Mode 


(b) Last bit before EoF is Logic "0" 


Figure 27: Reader-Reader Data Delay (RRDD) 


Requirements 102: Reader-Reader Data Delay (RRDD) 
Poll Mode 


8.7.1.1 When transmitting a series of successive Poll Frames, the NFC Forum Device 
MUST separate the frames through the RRDD. The NFC Forum Device MUST 
wait for a time no less than 


e RRDDumngrro, if the last transmitted data bit was Logic “0”, or 
es RRDDumngrr if the last transmitted data bit was Logic “1” 


before transmitting the next Poll Frame. RRDD MUST be measured from the 
rising edge of the last V2 in the preceding frame to the falling edge of the first V2 
of the subsequent frame, as illustrated in Figure 27. Refer to Appendix A.4 for the 
values of RRDDumn,siro and RRDDunmn,r:i- 


8.7.2 Frame Delay Time 
NFC Forum Devices configured for the Type 1 Tag platform use NFC-A Frame Delay Times. 
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Requirements 103: Frame Delay Times - Type 1 Tag Platform 
Poll Mode Listen Mode 


8.7.2.1 Commands and Responses Commands and Responses specified in 


specified in Section 8 (Type 1 Tag Section 8 (Type 1 Tag platform) HAS TO be 
platform) MUST be transmitted transmitted according to NFC-A Technology 


according to NFC-A Technology Frame Delay Time restrictions, as defined in 
defined in Section 4.10.1 and 
Section 4.10.2. 
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9.1 Sequence Format 


Type 2 Tag Platform 


The Type 2 Tag platform uses the NFC-A synchronization mechanism. 


Requirements 104: Sequence Format - Type 2 Tag Platform 


Poll Mode 


9.1.1.1 Commands and Responses 
specified in this section (Type 2 
Tag platform) MUST be 
transmitted using NFC-A 
Technology sequence format as 


defined in Section 4.1. 


9.2 Bit Level Coding 


Listen Mode 


Commands and Responses specified in this 
section (Type 2 Tag platform) HAVE TO be 
transmitted using NFC-A Technology sequence 
format as defined in Section 4.1. 


The Type 2 Tag platform uses NFC-A bit level coding. 


Requirements 105: Bit Level Coding - Type 2 Tag Platform 


Poll Mode 


9.2.1.1 Commands and Responses 
specified in this section (Type 2 
Tag platform) MUST be 
transmitted using NFC-A 
Technology bit level coding as 


defined in Section 4.2. 


9.3 Frame Format 


Listen Mode 


Commands and Responses specified in this 
section (Type 2 Tag platform) HAVE TO be 
transmitted using NFC-A Technology bit level 
coding as defined in Section 4.2. 


The Type 2 Tag platform transmits Commands and Responses in NFC-A standard frames, except 


for the ACK and NACK Response. 


A Listen Frame for the ACK and NACK Response consists of a short frame with 4 data bits (see 


Section 4.3.2). 


Requirements 106: Frame Format - Type 2 Tag Platform 


Poll Mode 


9.3.1.1 Commands and Responses 
specified in this section (Type 2 
Tag platform), except for the 
ACK and NACK Response, 
MUST be transmitted using 


NFC-A Technology standard 


frames as defined in Section 4.3. 
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Listen Mode 


Commands and Responses specified in this 
section (Type 2 Tag platform), except for the 
ACK and NACK Response, HAVE TO be 
transmitted using NFC-A Technology standard 
frames as defined in Section 4.3. 
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Requirements 107: Frame Format - ACK and NACK Response 


Poll Mode 


A Listen Frame for the ACK and 
NACK Response MUST consist 
of four data bits to be transmitted 
Isb first, as shown in Figure 28, 
and MUST begin with an SoF, as 
defined in Section 4.3. 


9.3.1.2 


9.4 


Data and Payload Format 


Listen Mode 


A Listen Frame for the ACK and NACK 
Response HAS TO consist of four data bits to 
be transmitted lsb first, as shown in Figure 28, 
and HAS TO begin with an SoF, as defined in 
Section 4.3. 


Type 2 Tag data transmitted in an NFC-A standard frame, i.e., the bytes following the SoF, have 
the following substructure. They consist of the payload and, depending on the payload, of the 


EoD. 


The payload consists of the Commands and Responses as described in Section 9.5. 


If present, the EoD contains a 2-byte checksum referred to as CRC_A. Input for CRC A 
calculation is the payload. If the payload consists of the ACK or NACK Response, then EoD is 


not present. 


Type 2 Tag data and payload format is illustrated in Figure 28. 


Data 


Payload 


EoD 


Byte 1 Byte 2 


Byten | CRC A1 | CRC A2 


Figure 28: Data and Payload Format - Type 2 Tag (except for ACK and NACK Response) 


Requirements 108: Data and Payload Format - Type 2 Tag 


Poll Mode 


9.4.1.1 If the payload consists of a 
Command or Response different 
from the ACK or NACK 
Response, then the payload 
MUST be followed by an EoD at 
the position, as indicated in 
Figure 28, and the EoD MUST 


contain a CRC A. 


Otherwise, the EoD MUST not be 
present. 


9.4.1.2 The CRC. A MUST be calculated 
and verified as specified in 


Section 4.4. 
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Listen Mode 


If the payload consists of a Command or 
Response different from the ACK or NACK 
Response, then the payload HAS TO be 
followed by an EoD at the position, as 
indicated in Figure 28, and the EoD HAS TO 
contain a CRC A. 

Otherwise, the EoD does not HAVE TO be 
present. 


The CRC. A HAS TO be calculated and 
verified as specified in Section 4.4. 
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9.5 Command Set 


Payload exchanged between NFC Forum Devices consists of Commands and Responses. 

Table 50 lists the Commands that are available to the NFC Forum Device in Poll Mode for 
communication with an NFC Forum Device in Listen Mode configured for the Type 2 Tag 
platform. For each Command, the corresponding Response from the NFC Forum Device in Listen 
Mode is indicated. 


The READ Command and Response are specified in Section 9.6. Refer to [T2TOP] for the 
coding of the remaining Commands and for the Type 2 Tag platform operation. Command 
parameters and names are defined in [T2TOP]. 


Table 50: Command Set 


Poll Mode (Command) Listen Mode (Response) 
READ Command READ Response, NACK Response 
WRITE Command ACK Response, NACK Response 


SECTOR SELECT Command ACK Response, NACK Response, Passive ACK Response 


9.0 READ 


[T2TOP] is the normative reference for this section. 


9.6.1 Command 


The format of the READ Command is shown in Table 51. Refer to [T2TOP] for further details 
regarding syntax and semantic of the READ Command. 


Table 51: READ Command Format 


Byte 1 Byte 2 
30h BNo 


9.6.2 Response 


In response to the READ Command, the NFC Forum Device returns a READ Response or a 
NACK response. 


Requirements 109: READ Response 


Poll Mode Listen Mode 
9.6.2.1 The NFC Forum Device MUST be 9.6.2.2 If the NFC Forum Device receives a 
ready to receive a READ Response READ Command, then it HAS TO 
with a payload composed of 16 return a READ Response with a 
bytes or a NACK response. payload composed of 16 bytes or a 
NACK response. 


The format of the READ Response is shown in Table 52. 
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Table 52: READ Response Format 
Byte 1 - 16 
payload 


Refer to [T2TOP] for further details regarding the payload coding. 
The format of the NACK Response is shown in Table 53. 
Table 53: NACK Response Format 


b4 b3 b2 bi Meaning 
0 x 0 x The NACK Response has a value of 0h, 1h, 4h, or 5h. 


Requirements 110: NACK Response 
Poll Mode 


9.6.2.3 When a NACK Response is received by the NFC Forum Device, this MUST be treated 
as Protocol Error. 


9.7 WRITE 


[T2TOP] is the normative reference for this section. 


9.7.1 Command 


The format of the WRITE Command is shown in Table 54. Refer to [T2TOP] for further details 
regarding syntax and semantic of the WRITE Command. 


Table 54: WRITE Command Format 


Byte 1 Byte 2 Byte 3-6 
A2h BNo Data 


9.7.2 Response 


In response to the WRITE Command, the NFC Forum Device returns an ACK or NACK 
response. 


Requirements 111: WRITE Response 


Poll Mode Listen Mode 

9.7.2.1 When an ACK Response is received, 9.7.2.2 If the NFC Forum Device receives 
the WRITE Command MUST be a WRITE Command, it HAS TO 
treated as being successful. return an ACK Response or a 
A NACK Response MUST be NACK Response. 


treated as Protocol Error. 
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The format of the ACK Response is shown in Table 55. The format of the NACK Response is 
shown in Table 53. 


Table 55: ACK Response Format 


b4 b3 b2 bi Meaning 
1 0 1 0 The ACK Response has a value of Ah. 


9.8 SECTOR SELECT 


[T2TOP] is the normative reference for this section. 

The SECTOR SELECT Command is composed of two command packets, called SECTOR 
SELECT Command Packet 1 and SECTOR SELECT Command Packet 2. 

9.8.1 SECTOR SELECT Command Packet 1 


The format of the SECTOR SELECT Command Packet 1 is shown in Table 56. Refer to 
[T2TOP] for further details regarding syntax and semantic of the SECTOR SELECT Command 
Packet 1. 


Table 56: SECTOR SELECT Command Packet 1 Format 


Byte 1 Byte 2 
C2h "BP" 


9.8.2 SECTOR SELECT Command Packet 2 


The format of the SECTOR SELECT Command Packet 2 is shown in Table 57. Refer to 
[T2TOP] for further details regarding syntax and semantic of the SECTOR SELECT Command 
Packet 2. 


Table 57: SECTOR SELECT Command Packet 2 Format 


Byte 1 Byte2-4 
SNo RFU 


9.8.8 Response 


In response to the SECTOR SELECT Command Packet 1, the NFC Forum Device returns an 
ACK or NACK response. The format of the ACK Response is shown in Table 55. The format of 
the NACK Response is shown in Table 53. If the Poll Frame contains an SECTOR SELECT 
Command Packet 2, then FDT 4 visten,max is equal to PATrzrsi Max. 
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9.8.3.1 


Type 2 Tag Platform 


Requirements 112: SECTOR SELECT Command Packet 1 Response 


When a SECTOR SELECT 
Command Packet 1 has been sent 
by the NFC Forum Device and an 
ACK Response is received, the 
SECTOR SELECT Command 
Packet 1 MUST be treated as 
being successful. 


A NACK Response MUST be 
treated as Protocol Error. 


Listen Mode 


9.8.3.2 


If the NFC Forum Device receives a 
SECTOR SELECT Command Packet 
1, then it HAS TO return an ACK or 
NACK Response. 


In response to the SECTOR SELECT Command Packet 2, the NFC Forum Device returns a 
Passive ACK Response. 


Poll Mode 


9.8.3.3 


Requirements 113: Passive ACK Response 


When a SECTOR SELECT 
Command Packet 2 has been sent 
by the NFC Forum Device, and no 
response is received within 
PATr2rsL Max after the SECTOR 
SELECT Command Packet 2, then 
the SECTOR SELECT Command 
Packet 2 MUST be treated as 
being successful (i.e., 

FDT a isrEN,MAX equals 
DAT et MAX) 


Refer to Appendix A D for the 
value of PATrzrsL Max, 


When a SECTOR SELECT 
Command Packet 2 has been sent 
by the NFC Forum Device, and a 
response is received within 
PATrzrsLMAx after the SECTOR 
SELECT Command Packet 2, then 
the SECTOR SELECT Command 
Packet 2 MUST be treated as a 
Protocol Error. 
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Listen Mode 


9.8.3.4 


If the NFC Forum Device receives a 
SECTOR SELECT Command Packet 
2, it is free to return a NACK 
Response or no Response within 

PAT 21,s_,max Of the reception of the 
SECTOR SELECT Command Packet 
2 (i.e., FDT a visten,Mmax equals 

PAT 21,sL,max)- It does not HAVE 
TO respond after DAT et MAN, 
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The Type 2 Tag platform uses NFC-A Frame Delay Times. 


Poll Mode 


9.9.1.1 


9.9.1.3 


Type 2 Tag Platform 


Requirements 114: Frame Delay Times - Type 2 Tag Platform 


Commands and Responses specified 9.9.1.2 


in this section (Type 2 Tag 
platform) MUST be transmitted 
according to NFC-A Technology 
Frame Delay Time restrictions, as 
defined in Section 4.10.1 and 
Section 4.10.2. 


Regarding the maximum Frame 
Delay Time Poll—Listen, 
Requirement 9.9.1.3 MUST be 
applied. 


The NFC Forum Device MUST 


wait for a Response at least for time: 


e FDTzrggap,uax for the READ 
Command 


e FDTrrwnrgMax for the 
WRITE Command 

e FDTrzrsi ax for the SECTOR 
SELECT Command Packet 1 

If the NFC Forum Device does not 

receive a Response within 

FDT rzrREADIWRITEISL,MAX * ATpotL, 

then the NFC Forum Device MUST 

treat this as a Timeout Error (i.e., 

FDT 4 visten,max equals 

FDT +27, READIWRITEISL,MAX + ATpo.t)- 

Refer to Appendix A.5 for the 

values of FDTrzzrREADMAX: 

FDTzr unire MAX FDTirsi Ax 


and AT»poLL. 


Between FD T72T,READIWRITE/SL,MAX and 

FDT 2r. READwRITE/SL MAX +AT sot, the NFC 
Forum Device MAY accept the Response or 
MAY generate a Timeout Error. 


Note: See Section 9.8.3.3 for the definition of the 


passive ACK response and timing for the 
SECTOR SELECT Command Packet 2. 
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Listen Mode 


Commands and Responses specified 
in this section (Type 2 Tag 
platform) HAVE TO be transmitted 
according to NFC-A Technology 
Frame Delay Time restrictions, as 
defined in Section 4.10.1 and 
Section 4.10.2. 

Regarding the maximum Frame 
Delay Time Poll—Listen, 
Requirement 9.9.1.3 HAS TO be 
applied. 


The NFC Forum Device HAS TO respond no 


later than: 
FDTr2r.READ,MAX for the READ Command 


FDT rr, wnirE MAX for the WRITE Command 


FDTrər,sL,max for each packet of the 
SECTOR SELECT Command 


(i.e., FDT 4 LisrEN,MAX equals 
F. D TT2T,READ/WRITE/SL,MAX) 
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10 Type 3 Tag Platform 


Implementation of Type 3 Tag platform Listen Mode is optional. However, if implemented, then 
it has to be implemented as specified here (see Requirements 1.10.1.1). 


10.1 Sequence Format 
The Type 3 Tag platform uses the NFC-F synchronization mechanism. 
Requirements 115: Sequence Format - Type 3 Tag Platform 
Poll and Listen Mode 


10.1.1.1 Commands and Responses specified in Section 10 (Type 3 Tag platform) MUST 
be transmitted using NFC-F Technology sequence format as defined in 
Section 6.1. 


10.2 Bit Level Coding 
The Type 3 Tag platform uses NFC-F bit level coding. 
Requirements 116: Bit Level Coding - Type 3 Tag Platform 
Poll and Listen Mode 


10.2.1.1 | Commands and Responses specified in Section 10 (Type 3 Tag platform) MUST 
be transmitted using NFC-F Technology bit level coding as defined in Section 6.1. 


10.3 Frame Format 
The Type 3 Tag platform transmits Commands and Responses in NFC-F frames. 
Requirements 117: Frame Format - Type 3 Tag Platform 
Poll and Listen Mode 


10.3.1.1 | Commands and Responses specified in Section 10 (Type 3 Tag platform) MUST 
be transmitted using NFC-F Technology frames as defined in Section 6.2. 


10.4 Data and Payload Format 


Type 3 Tag data follow the data and payload format as specified in Section 6.4 for NFC-F 
Technology. 


Requirements 118: Data and Payload Format - Type 3 Tag 
Poll and Listen Mode 


10.4.1. | Commands and Responses specified in Section 10 (Type 3 Tag platform) MUST 
be transmitted using NFC-F Technology data and payload format as defined in 
Requirements 6.4.1.2 to 6.4.1.5. 
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10.5 Command Set 


Payloads exchanged between NFC Forum Devices consist of Commands and Responses. 

Table 58 lists the Commands that are available to the NFC Forum Device in Poll Mode for 
communication with an NFC Forum Device in Listen Mode configured for the Type 3 Tag 
platform, after device activation. For each Command, the corresponding Response from the NFC 
Forum Device in Listen Mode is indicated. The CHECK Command is used to retrieve 
information regarding the NDEF capabilities of the responding NFC Forum Device. 


Refer to [T3TOP] for the format of the POLLING, CHECK, and UPDATE Commands and 
Responses. 


Table 58: Command Set 


Poll Mode (Command) Listen Mode (Response) 
POLLING Command POLLING Response 
CHECK Command CHECK Response 
UPDATE Command UPDATE Response 


10.6 Timing Requirements 


The Type 3 Tag platform uses NFC-F Frame Delay Times. Contents, when already defined 
elsewhere, have been included in this section for readability reasons. Timing requirements on 
SENSF REQ and SENSF RES are described in Section 6.7. 


The Type 3 Tag platform uses the Maximum Response Time (MRT) for the timing requirements. 


The MRTI for the CHECK Command (MRTlcugck) and for the UPDATE Command 
(MRTluppate) defines the MRT within which the (NFC Forum Device in Listen Mode configured 
for emulating the) Type 3 Tag platform has to send the SoD of its Response after the EoD of a 
Poll Frame containing the CHECK Command or UPDATE Command, respectively. MRT is 
calculated by the following formula, applicable for MRTcugck and MRTyppare: 


MRT = T x ((A*1) + n (B+1)) x 4° 
where: 


e The parameter n denotes the size of the Block field (i.e., the number of blocks) in the 
CHECK Command or in the UPDATE Command, as defined in [T3TOP]. 


e The parameters A, B, and E for the CHECK Command are transmitted to the NFC Forum 
Device in Poll Mode in the MRTlcueck field of the SENSF RES Response, as defined in 
Table 59 and Section 6.6.2. 


e The parameters A, B, and E for the UPDATE Command are transmitted to the NFC Forum 
Device in Poll Mode in the MRTluppate field of the SENSF. RES Response, as defined in 
Table 59 and Section 6.6.2. 


The value of T is given in Appendix A.6. 


The FDTevisten,max defined in Section 6.7 equals MRT - 16 bd (where 16 bd is the bit duration 
of the SoF). 
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Table 59: Format of MRTloueck and MRTluppate 


b6 b5 b4 b3 b2 bi 


Requirements 119: MRT cHeck 


Following the CHECK Command, 
the NFC Forum Device MUST wait 
at least MRTcugck + ARWT for the 
SoD of the Response. 

If the NFC Forum Device does not 
receive the SoD of the Response 
within MRTcugck + ARWT + 
ATpoxt, then the NFC Forum 
Device MUST treat this as a 
Timeout Error. 

Refer to Appendix A.6 for the 
values of ARWT and ATpo-. 


Between MRT cHeck + ARWT and MRT cHecx F 
ARWT +ATpoL, the NFC Forum Device MAY 
accept the Response or MAY generate a Timeout 


Error. 


Poll Mode 


10.6.1.3 


Requirements 120: MRTuppate 


Following the UPDATE Command, 
the NFC Forum Device MUST wait 
at least MRTuppate + ARWT for the 
SoD of the Response. 

If the NFC Forum Device does not 
receive the SoD of the Response 
within MRTouppate + ARWT 

+ ATpoi, then the NFC Forum 
Device MUST treat this as a 
Timeout Error. 


Refer to Appendix A.6 for the 
values of ARWT and ATpo-. 


Between MRTuppate + ARWT and MRT uppate 
+ ARWT + ATpo.t, the NFC Forum Device 
MAY accept the Response or MAY generate a 
Timeout Error. 


NFC Digital Protocol 


Meaning 


Parameter A 


Parameter B 


Parameter E 


Listen Mode 


10.6.1.2 


Following the EoD of the CHECK 
Command, the NFC Forum Device 
MUST wait no longer than 
MRTcueck before sending the SoD 
of the Response. 


Listen Mode 


10.6.1.4 


Following the EoD of the UPDATE 
Command, the NFC Forum Device 
MUST wait no longer than 
MRTuppate before sending the SoD 
of the Response. 
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11 Type 4A Tag Platform 


Implementation of Type 4A Tag platform Listen Mode is optional. However, if implemented, 
then it has to be implemented as specified here (see Requirements 1.10.1.1). 


11.1 Sequence Format 
The Type 4A Tag platform uses the NFC-A synchronization mechanism. 
Requirements 121: Sequence Format - Type 4A Tag Platform 
Poll and Listen Mode 


11.1.1.1 Commands and Responses specified in Section 11 (Type 4A Tag platform) MUST 
be transmitted using NFC-A Technology sequence format as defined in 
Section 4.1. 


11.2 Bit Level Coding 
The Type 4A Tag platform uses NFC-A bit level coding. 
Requirements 122: Bit Level Coding - Type 4A Tag Platform 
Poll and Listen Mode 


11.2.1.1 | Commands and Responses specified in Section 11 (Type 4A Tag platform) MUST 
be transmitted using NFC-A Technology bit level coding as defined in Section 4.2. 


11.3 Frame Format 
The Type 4A Tag platform transmits Commands and Responses in NFC-A standard frames. 
Requirements 123: Frame Format - Type 4A Tag Platform 
Poll and Listen Mode 


11.3.1. | Commands and Responses specified in this section (Type 4A Tag platform) MUST 
be transmitted using NFC-A Technology standard frames as defined in Section 4.3. 


11.4 Data and Payload Format 


During the Device Activation Activity, Type 4A Tag data has the following substructure, which 
consists of the payload and of an EoD. 


The payload consists of the Commands and Responses as described in Section 11.5. 


The EoD contains a two-byte checksum referred to as CRC_A. Input for CRC_A calculation is 
the payload. 
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Figure 29 illustrates the Type 4A Tag data and payload format. 


Data 
Payload EoD 
Byte 1 Byte 2 ez Byten | CRC A1 | CRC A2 


Figure 29: Data and Payload Format - Type 4A Tag 


Requirements 124: Data and Payload Format - Type 4A Tag 
Poll and Listen Mode 


11.4.1.4 The payload MUST be followed by an EoD at the position, as indicated in Figure 29. 
The EoD MUST contain a CRC A. 


11.4.1.2 The CRC_A MUST be calculated and verified as specified in Section 4.4. 


11.5 Command Set 


Payloads exchanged between NFC Forum Devices consist of Commands and Responses. 

Table 60 lists the Commands that are available to the NFC Forum Device in Poll Mode for 
communication with the (NFC Forum Device in Listen Mode configured for emulating the) Type 
4A Tag platform during the Device Activation Activity. For each Command, the corresponding 
Response from the NFC Forum Device in Listen Mode is indicated. 


Table 60: Command Set 


Poll Mode (Command) Listen Mode (Response) 
RATS ATS 


Refer to [T4TOP] for the definition of the high level command set. 


11.6 Request for Answer to Select (RATS) 


The RATS Command is used by the NFC Forum Device in Poll Mode during the Device 
Activation Activity to negotiate the maximum frame size and the bit rate divisors (D) with the 
NFC Forum Device in Listen Mode. 


11.6.1 RATS Command 
Table 61 specifies the code for the RATS Command. 


Table 61: Format of RATS Command 
Byte 1 Byte 2 
EOh PARAM 
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PARAM, the parameter byte, consists of two parts as shown in Table 62. 


Table 62: Format of RATS Parameter Byte (PARAM) 


b8 b7 b6 b5 b4 b3 b2 bi Meaning 
x x x x FSDI 


X X X X DID 


The most significant nibble b8 to b5 is called FSDI (Frame Size for proximity coupling Device 
Integer) and codes FSD (Frame Size for proximity coupling Device). The FSD defines the 
maximum size of a frame that the NFC Forum Device in Poll Mode is able to receive. FSD is 
expressed in number of data bytes included in the frame. 


Requirements 125: Frame Size for NFC Forum Device in Poll Mode (FSD) 


Poll Mode Listen Mode 

11.6.1.1 The NFC Forum Device MUST 11.6.1.2 The NFC Forum Device MUST 
accept frames with a number of data send frames with a number of data 
bytes less than or equal to FSD. The bytes less than or equal to FSD. 


NFC Forum Device MUST resort to 
exception processing (Protocol 
Error) if it receives a frame with 
more than FSD data bytes. 


11.6.1.3 The FSD supported by the NFC 11.6.1.4 The NFC Forum Device MUST 
Forum Device MUST be FSDmn. support an FSD equal to FSDmn. 
Refer to Appendix A.7 for the value The NFC Forum Device MAY support an FSD 
of FSDun. less than FSDuyww. 


Table 63 provides the coding of FSD in terms of FSDI. 


Table 63: FSDI to FSD Conversion 


FSDI Oh 1h 2h 3h 4h 5h 6h 7h 8h 9h-Eh Fh 
FSD (bytes) 16 24 32 40 48 64 96 128 256 RFU 256 


Requirements 126: FSDI yin 
Poll Mode 


11.6.1.5 The NFC Forum Device MUST set FSDI equal to 8h or Fh. 
FSDI set to Fh indicates support of advanced protocol parameters. 
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Requirements 127: Listen Mode Handling of RFU Values of FSDI 
Listen Mode 
11.6.1.6 A received value of FSDI = 9h-Eh MUST be treated by the NFC Forum Device as 
FSDI = Fh. 
NOTE Requirements 11.6.1.5 and 11.6.1.6 and Table 63 overrule [ISO/IEC 14443]. 


The least significant nibble b4 to b1 is named DID, and it defines the logical number of the 
addressed NFC Forum Device in Listen Mode in the range from 0 to 14 (DID - 15 is not 
allowed). 


NOTE The term CID as used in [ISO/IEC 14443] is referred to as DID in this document. 


Requirements 128: Support of DID 


Poll Mode Listen Mode 

11.6.1.7 The NFC Forum Device MUST set 11.6.1.8 The NFC Forum Device MUST 
the DID field to a value between 0 support a DID field with a value 
and 14. between 0 and 14. 


Requirements 129: Listen Mode Handling of RFU Value of DID 
Listen Mode 


11.6.1.9 The NFC Forum Device MUST treat a DID=15 as Protocol Error. 


11.6.2 RATS Response (Answer To Select) 


The Answer To Select (ATS) is transmitted by the NFC Forum Device in Listen Mode in 
response to the RATS Command. This section defines the ATS with all its available fields, as 
shown in Table 64. 


Table 64: Structure of the ATS 


Byte1 ` Baute 3 Byte 3 Byte 4 Byte 5 Byte 6 - 6+k-1 
TL TO TA(1) TB(1) TC(1) T1... Tk 


The length byte TL is followed by a variable number of bytes in the following order: 
e Format byte TO, 

e Interface bytes TA(1), TB(1), TC(1), and 

e Historical bytes T1 to Tk. 
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The parameter k denotes the number of historical bytes. 
e Length byte 


The length byte TL is mandatory and specifies the length of the transmitted ATS, including 
the TL byte itself. 


Requirements 130: Length Byte TL of the ATS 
Poll Mode Listen Mode 


11.6.2.1 The first byte of the ATS (TL) 
MUST specify the length of the 
ATS including TL itself. 


11.6.2.2 The NFC Forum Device MUST be 11.6.2.3kX TL MUST not indicate a length 
ready to receive an ATS with TL greater than 20 bytes. 
specifying a length less than or 
equal to 20 bytes. 


The NFC Forum Device MAY accept an ATS 
with TL indicating a length greater than 20 
bytes. 


e Format Byte TO 
The format byte TO is coded as specified in Table 65. 
Table 65: Coding of Format Byte TO 


b8 b7 b6 b5 b4 b3 b2 bi = Meaning 
0 RFU 


x TC(1) is transmitted, if bit is set to 1 


x TB(1) is transmitted, if bit is set to 1 


x TA(1) is transmitted, if bit is set to 1 


X X X X FSCI 


The least significant nibble b4 to b1 is called FSCI (Frame Size for proximity Card Integer) and 
codes the maximum frame size (FSC). The FSC defines the maximum size of a frame accepted 
by the NFC Forum Device in Listen Mode. FSC is expressed in number of data bytes included in 
the frame. 
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Requirements 131: FSC 


Poll Mode Listen Mode 
11.6.2.4 The NFC Forum Device MUST 11.6.2.5 The NFC Forum Device MUST 
send frames with a number of data accept frames with a number of 
bytes less than or equal to FSC. data bytes less than or equal to 
FSC. 


The NFC Forum Device MUST 
resort to exception processing 
(Protocol Error) if it receives a 
frame with more than FSC data 


bytes. 

11.6.24. The NFC Forum Device MUST 11.6.2.7 The FSC supported by the NFC 
be capable of sending frames in Forum Device MUST be at least 
accordance with an FSC greater FSCyumn. 
than or equal to FSC. Refer to Appendix A.7 for the 

value of FSCwin. 


Table 66 specifies the coding of FSC in terms of FSCI. The default value of FSCI is 2 and leads 
to a FSC of 32 bytes. 


Table 66: FSCI to FSC Conversion 


FSCI Oh 1h 2h 3h 4h 5h 6h 7h 8h 9h-Fh 
FSC (bytes) 16 24 32 40 48 64 96 128 256 RFU 


Requirements 132: FSCI 
Listen Mode 


11.6.2.8 The NFC Forum Device MUST set FSCI greater than or equal to the value 
corresponding to FSCyin with a maximum value of 8h. Refer to Appendix A.7 for 
the value of FSCywin. Refer to Table 66 for FSCI to FSC conversion. 


Requirements 133: Poll Mode Handling of RFU Values of FSCI 
Poll Mode 


11.6.2.9 A received value of FSCI = 9h-Fh MUST be treated by the NFC Forum Device as 
FSCI - 8h. 
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Requirements 134: Format Byte TO of the ATS 


Poll Mode Listen Mode 

11.6.2.10 The NFC Forum Device MUST be 11.6.2.11  TA(1), TB(1) and TC(1) MUST be 
ready to receive an ATS including present in the ATS and the 
TO, TA(1), TB(1), and TC(1). If presence MUST be indicated in 
one or more of the fields TO, TO. 


TA(1), TB(1), and TC(1) are 
missing, then the NFC Forum 
Device MUST use the default 
values as specified in this section. 


e Interface Byte TA(1) 


The interface byte TA(1) conveys information to define the bit rate capabilities of the NFC 
Forum Device in Listen Mode. The interface byte TA(1) is coded as specified in Table 67. 
The bits b7 to b5 code the bit rate capability of the NFC Forum Device in Listen Mode for the 
direction from NFC Forum Device in Listen Mode to NFC Forum Device in Poll Mode 
(DusreNPoLL)- The default value for the bits b7 to b5 is 000b (DusreN S PoLL = 1). The bits b3 
to b1 code the bit rate capability of the NFC Forum Device in Listen Mode for the direction 
from NFC Forum Device in Poll Mode to NFC Forum Device in Listen Mode 

(DeoiL S uisrEN). The default value for the bits b3 to b1 is 000b (Deet LisTEN Ke 1). 


Table 67: Coding of Interface Byte TA(1) 


b8 b7 b6 b5 b4 b3 b2 bi Meaning 


x If b8 = 1b, then only the same bit rate divisor for 
both directions is supported 
(Dusten+pott=Dpottsusten)- 
If b8 = Ob, then a different bit rate divisor for each 
direction is supported. 


x DiisrEN POLL -8 supported, if bit is set to 1b. 


X DiisrEN POLL -4 supported, if bit is set to 1b. 


X DiisrEN POLL -2 supported, if bit is set to 1b. 


0 RFU 


X DPoLL>LISTEN =8 supported, if bit is set to 1b. 


X DPoLL>LISTEN =4 supported, if bit is set to 1b. 


X DPoLL>LISTEN =2 supported, if bit is set to 1b. 
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Requirements 135: Format Byte TA(1) of the ATS 


Poll Mode Listen Mode 

11.6.2.12 The NFC Forum Device MUST 11.6.2.13 In response to a RATS Command 
support a bit rate of 106 kbits/s in with FSDI of PARAM (byte 2) set 
both directions. to 8h, the NFC Forum Device 

The NFC Forum Device MAY support higher MUST set the bits b7 to b5 and b3 

bit rates. to b1 of TA(1) equal to Ob, 


indicating that it supports only a bit 
rate of 106 kbits/s in both 
directions. 


The NFC Forum Device MAY indicate support 
for higher bit rates in response to a RATS 
Command with FSDI of PARAM (byte 2) set to 
a value of Fh. 


Requirements 136: Poll Mode Handling of RFU Value of b4 of Interface Byte TA(1) 
Listen Mode 


11.6.2.14 A received RFU value of b4 = 1b MUST be interpreted by the NFC Forum Device 
in Poll Mode as if b7 to b1 = 0000000b (only 106 kbits/s in both directions). 


NOTE Higher bit rates will be specified in next versions of this specification. 


Interface Byte TB(1) 


The interface byte TB(1) conveys information to define the Frame Waiting Time (FWT) and 
the Start-up Frame Guard Time (SFGT). The interface byte TB(1) is coded as specified in 
Table 68. 


Table 68: Coding of Interface Byte TB(1) 


b8 b7 b6 b5 b4 b3 b2 b1 Meaning 
X X X X FWI 


X X X X SFGI 


e The most significant nibble b8 to b5 is called FWI (Frame Waiting time Integer) and 
codes the Frame Waiting Time (FWT) for the subsequent Commands. Refer to Section 
11.7 for the definition of the FWT. FWI has a value in the range from 1 to 14. The value 
15 is RFU. The default value of FWI is 4. 
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Requirements 137: Interface Byte TB(1) of the ATS 


Poll Mode Listen Mode 

11.6.2.15 The NFC Forum Device in Poll 11.6.2.16 The NFC Forum Device MUST 
Mode MUST support an ATS set FWI less than or equal to 
with TB(1) indicating an FWI FWlyax. 


less than or equal to FWImax. Refer to Appendix A.7 for the 


value of FWlyax. 


Requirements 138: Poll Mode Handling of RFU Value of FWI 
Poll Mode 


11.6.2.17 A received value of FWI = 15 MUST be treated by the NFC Forum Device as 
FWI - 4. 


e The least significant nibble b4 to b1 codes SFGI (Start-up Frame Guard time Integer) and 
is used by the NFC Forum Device in Listen Mode to code a multiplier value used to 
define the SFGT. Refer to Section 11.7 for the definition of SFGT.SFGI has a value in 
the range from 1 to 14. The value 15 is RFU. The default value of SFGI is 0. 


Requirements 139: Interface Byte TB(1) of the ATS 


Poll Mode Listen Mode 

11.6.2.18 The NFC Forum Device MUST  11.6.2.19 The NFC Forum Device MUST 
be ready to receive an ATS with set SFGI less than or equal to 
TB(1) indicating an SFGI less SFGlyax. 
than or equal to SFGlyax. Refer to Appendix A.7 for the 


value of SFGlyax. 


Requirements 140: Poll Mode Handling of RFU value of SFGI 
Poll Mode 


11.6.2.20 A received value of SFGI = 15 MUST be treated by the NFC Forum Device as 
SFGI = 0. 
e Interface Byte TC(1) 


The interface byte TC(1) indicates whether advanced protocol features NAD and DID are 
supported by the NFC Forum Device in Listen Mode. The interface byte TC(1) is coded as 
specified in Table 69. 
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Table 69: Coding of Interface Byte TC(1) 


b8 b7 b6 b5 b4 b3 b2 b1 Meaning 
0 0 0 RFU 


x Ob: Advanced protocol features not supported 
1b: Advanced protocol features supported 


0 0 RFU 


x DID supported, if bit is set to 1b 


x NAD supported, if bit is set to 1b 


The bits b2 and b1 are used by the NFC Forum Device in Listen Mode to indicate which optional 
fields in the SoD it supports. Bit b1 set to 1b indicates NAD supported; b2 set to 1b indicates DID 
supported. Refer to Section 13.1 for the specification of the SoD. 


Bit b5 is used to indicate whether the NFC Forum Device in Listen Mode supports advanced 
protocol features. 


Requirements 141: NAD 


Poll Mode Listen Mode 

11.6.2.21 The NFC Forum Device MUST not 11.6.2.22 The NFC Forum Device MUST 
use NAD and MUST disregard any not support NAD and set b1 
value returned by the NFC Forum equal to Ob. 


Device in b1. 


e Historical Bytes 


The historical bytes T1 to Tk are optional and are used by the NFC Forum Device in Listen 
Mode to designate general information. The maximum length of the ATS gives the maximum 
possible number of historical bytes. 


Requirements 142: Historical Bytes of the ATS 


Poll Mode Listen Mode 

11.6.2.23 The NFC Forum Device MUST be 11.6.2.24 The NFC Forum Device MUST 
ready to receive an ATS with up to send no more than 15 historical 
15 historical bytes. bytes. 


The NFC Forum Device MAY accept an ATS 
with more than 15 historical bytes. 


11.7 Timing Requirements 


11.7.1 FWT 


The Frame Waiting Time (FWT) defines the time within which an NFC Forum Device in Listen 
Mode configured for the Type 4A Tag platform has to start its Response after the end of a Poll 
Frame and is calculated by the following formula: 
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where the value of FWI has the range from 0 to 14 and is provided by the RATS Response as 


specified in Section 11.6.2. 


The RATS Command includes a definition for a specific FWT. For this Command, the NFC 
Forum Device in Listen Mode starts sending its Response frame within FWTactivation 
(activation frame waiting time). Refer to Section 11.6.1 for the definition of the RATS Command. 


Requirements 143: Frame Timing - Type 4A Tag Platform 


Poll Mode Listen Mode 


11.7.1.4 Following the RATS Command, the  11.7.1.2 
NFC Forum Device MUST wait at 
least FWT activation for the ATS. 
If the NFC Forum Device does not 
receive the ATS within 
FWT activation + ATpoL, then the 
NFC Forum Device MUST treat this 
as a Timeout Error (i.e., 
FDT A, isrEN,MAx equals 
FWT activation + ATpot)- 


Refer to Appendix A.7 for the value 
of ATpouL. 

Between FWT activation and 

FWT acrivation + AT pou, the NFC Forum 


Device MAY accept the ATS or MAY generate a 
Timeout Error. 


11.7.1.3 Except for the RATS Command, the 11.7.1.4 
NFC Forum Device MUST wait at 
least FWT+AFWT for a Response. 
Except for the RATS Command, if 
the NFC Forum Device does not 
receive a Response within 
FWT+AFWT + ATpoLL then the 
NFC Forum Device MUST treat this 
as a Timeout Error (i.e., 
FDT 4 isrEN.MAX equals 
FWT+AFWT + ATpouL). 
Refer to Appendix A.7 for the 
values of AFWT and ATpo i. 


Between FWT +AFWT and FWT - AFWT 
+ ATpo,,, the NFC Forum Device MAY accept 
the Response or MAY generate a Timeout Error. 
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The NFC Forum Device MUST 
start the ATS Response after the end 
of the RATS Command within 

FWT activation (i.e. 

FDT; visten,max equals 

FWT activation): 

Refer to Appendix A.7 for the value 
of FWTactwvation- 


Except for the RATS Command, the 
NFC Forum Device MUST start its 
Response after the end of a 
Command within the FWT (i.e., 
FDTa visten,max equals FWT). 
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11.7.2 SFGT 


The SFGT is the minimum time the NFC Forum Device in Poll Mode is waiting before the NFC 
Forum Device in Listen Mode is ready to receive the next frame after it has sent the RATS 
Response. Refer to Section 11.6.2 for the definition of the RATS Response. 


The SFGT is calculated: 
SFGT = (256 x 16/fc) x 2°"! 


Type 4A Tag Platform 


where SFGI has the range from 1 to 14 and is returned by the NFC Forum Device in Listen Mode 
in the interface byte TB(1) of the RATS Response. If the NFC Forum Device in Listen Mode 
returns SFGI equal to zero or SFGI is not returned, then no SFGT is needed and FDT A Got wm 


applies. 


Poll Mode 


11.7.2.1 


11.7.2.3 


Requirements 144: SFGT - Type 4A Tag Platform 


If the NFC Forum Device in Listen 
Mode returns an SFGI different 
from zero, the NFC Forum Device 
in Poll Mode MUST wait at least 
SFGT+ASFGT before sending the 
next frame after the NFC Forum 
Device in Listen Mode has sent the 
ATS. Refer to Appendix A.7 for the 
value of ASFGT. 


If the NFC Forum Device in Listen 
Mode returns an SFGI equal to zero 
or SFGI is not returned, the NFC 
Forum Device in Poll Mode MUST 
wait at least FDT a zo wm before 
sending the next frame after the 
NFC Forum Device in Listen Mode 
has sent the ATS. 


NFC Digital Protocol 


Listen Mode 


11.7.2.2 


If the NFC Forum Device in Listen 
Mode returns an SFGI different 
from zero, then the NFC Forum 
Device MUST be ready to receive 
the start of a new Poll Frame no 
later than SFGT after the end of the 
ATS frame. 


If the start of a new Poll Frame is received 
before SFGT, then the NFC Forum Device MAY 
treat this as a Transmission Error. 


11.7.2.4 


If the NFC Forum Device in Listen 
Mode returns an SFGI equal to zero 
or does not return an SFGI, then the 
NFC Forum Device MUST be ready 
to receive the start of a new Poll 
Frame no later than FDT A poit, ui 
after the end of the ATS frame. 


If the start of a new Poll Frame is received 
before FDT A sot tw, then the NFC Forum 
Device MAY treat this as a Transmission Error. 
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12 Type 4B Tag Platform 


Implementation of Type 4B Tag platform Listen Mode is optional. However, if implemented, 
then it has to be implemented as specified here (see Requirements 1.10.1.1). 


12.1 Sequence Format 
The Type 4B Tag platform uses the NFC-B synchronization mechanism. 
Requirements 145: Sequence Format - Type 4B Tag Platform 
Poll and Listen Mode 


12.1.1.1 | Commands and Responses specified in Section 12 (Type 4B Tag platform) MUST 
be transmitted using NFC-B Technology sequence format as defined in 
Section 5.1. 


12.2 Bit Level Coding 
The Type 4B Tag platform uses NFC-B bit level coding. 
Requirements 146: Bit Level Coding - Type 4B Tag Platform 
Poll and Listen Mode 


12.2.1.1 Commands and Responses specified in Section 12 (Type 4B Tag platform) MUST 
be transmitted using NFC-B Technology bit level coding as defined in Section 5.2. 


12.3 Frame Format 
The Type 4B Tag platform transmits Commands and Responses in NFC-B frames. 
Requirements 147: Frame Format - Type 4B Tag Platform 
Poll and Listen Mode 


12.3.1. Commands and Responses specified in Section 12 (Type 4B Tag platform) MUST 
be transmitted using NFC-B Technology frames as defined in Section 5.3. 


12.4 Data and Payload Format 
The payload consists of the Commands and Responses as described in Section 12.5. 
Requirements 148: Data and Payload Format - Type 4B Tag Platform 
Poll and Listen Mode 


12.4.1.1 Commands and Responses specified in Section 12 (Type 4B Tag platform) MUST 
be transmitted using the NFC-B Technology data and payload format as defined in 
Section 5.4. 
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12.5 Command Set 


Payload exchanged between NFC Forum Devices consists of Commands and Responses. 

Table 70 lists the Commands that are available to the NFC Forum Device in Poll Mode for 
communication with an NFC Forum Device in Listen Mode configured for the Type 4B Tag 
platform during the Device Activation Activity. For each Command, the corresponding Response 
from the NFC Forum Device in Listen Mode is indicated. 


Table 70: Command Set 


Poll Mode (Command) Listen Mode (Response) 
ATTRIB Command ATTRIB Response 


Refer to [T4TOP] for the definition of the high level command set. 


12.6 ATTRIB 


The ATTRIB Command is sent by the NFC Forum Device in Poll Mode during the Device 
Activation Activity in order to negotiate a set of communication parameters with the NFC Forum 
Device in Listen Mode. 


12.6.1 ATTRIB Command 
Table 71 defines the format of the ATTRIB Command. 
Table 71: ATTRIB Command Format 
Byte1 Byte2-5  Byte6 Byte 7 Byte 8 Byte 9 Byte 10 - 10+k-1 
1Dh NFCIDO Param 1 Param2  Param3  Param4 Higher layer - INF 


NFCIDO 


Byte 2 up to byte 5 include the NFCIDO sent by the NFC Forum Device in Listen Mode in the 
SENSB RES. 


Requirements 149: NFCIDO in ATTRIB Command 


Poll Mode Listen Mode 

12.6.1.1 The NFC Forum Device in Poll 12.6.1.2 The NFC Forum Device MUST 
Mode MUST send the ATTRIB recognize its own NFCIDO and 
Command using the NFCIDO respond only to a Valid ATTRIB 
received in the Valid Command in which its NFCIDO is 
SENSB RES Response from the included. 
NFC Forum Device in Listen 
Mode. 
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The NFC Forum Device in Poll Mode codes Param 1 with the values of minimum TRO and TR1, 
and whether SoS and EoS should be used. The format of Param 1 is specified in Table 72. 


Table 72: Format of Param 1 of the ATTRIB Command 


b8 b7 b6 


Meaning 


Minimum TRO 
00b: Default value 
01b: 48 x 16/fc 
10b: 16 x 16/fc 
11b: RFU 


Minimum TR1 
00b: Default value 
01b: 64 x 16/fc 
10b: 16 x 16/fc 
11b: RFU 


Suppression of EoS 
Ob: EoS required 
1b: EoS not required 


Suppression of SoS 
Ob: SoS required 
1b: SoS not required 


NFC Digital Protocol 


RFU 
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Requirements 150: Format of Param 1 of the ATTRIB Command 


Poll Mode 


12.6.1.3 If bit b4 of the ADC in the 
SENSB RES of the NFC Forum 
Device in Listen Mode is set to 
Ob, then the NFC Forum Device 
in Poll Mode MUST set b8 and b7 
equal to 00b, indicating that the 
default minimum value of TRO 


(TROwmmn) is to be used. 


Refer to Appendix A.2 for the 
value of TROwn. 


If bit b4 of the ADC in the SENSB_RES of the 
NFC Forum Device in Listen Mode is set to 
1b, then the NFC Forum Device in Poll Mode 
MAY set b8 and b7 to values different from 
00b, as indicated in Table 72. 


Listen Mode 


The NFC Forum Device MAY implement 
values different from 00b for Minimum TRO, 
as indicated in Table 72. 


12.6.1.4 If bit b4 of the ADC in the 
SENSB RES of the NFC Forum 
Device in Listen Mode is set to 
Ob, then the NFC Forum Device 
in Poll Mode MUST set b6 and b5 
equal to 00b, indicating that the 
default minimum value of TR1 


(TR1yin) is to be used. 


Refer to Appendix A.2 for the 
value of TRAyun. 


If bit b4 of the ADC in the SENSB RES of the 
NFC Forum Device in Listen Mode is set to 
1b, then the NFC Forum Device in Poll Mode 
MAY set b6 and b7 to values different from 
00b, as indicated in Table 72. 


The NFC Forum Device MAY implement 
values different from 00b for Minimum TR1, 
as indicated in Table 72. 


12.6.1.5  Ifbit b4 of the ADC in the 
SENSB RES of the NFC Forum 
Device in Listen Mode is set to 
Ob, then the NFC Forum Device 
in Poll Mode MUST set b4 and b3 
equal to 00b, indicating that it 
does not support suppression of 
SoS/EoS. 


If bit b4 of the ADC in the SENSB RES of the 
NFC Forum Device in Listen Mode is set to 
1b, then the NFC Forum Device in Poll Mode 
MAY set b4 and b3 to values different from 
00b, as indicated in Table 72. 


NFC Digital Protocol 


The NFC Forum Device in Listen 
Mode MUST not implement 
suppression of SoS/EoS for bit 
rates higher than fc/128. 


The NFC Forum Device MAY implement 
suppression of SoS/EoS for communication at 
fc/128. 


12.6.1.6 
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Requirements 151: Listen Mode Handling of RFU Values of Minimum TRO and TR1 


Listen Mode 


12.6.1.7 A received RFU value of 11b for Minimum TRO and Minimum TR1 MUST be 
interpreted as 00b, the default value. 


Param 2 
The NFC Forum Device in Poll Mode codes Param 2 as specified in Table 73. 
Table 73: Format of Param 2 of the ATTRIB Command 
b8 b7 b6 b5 b4 b3 b2 bi Meaning 


x x Bit rate Listen— Poll 


x x Bit rate Poll—Listen 


X X X X FSDI 


The least significant nibble (b4 to b1) of Param 2 is used by the NFC Forum Device in Poll Mode 
to code the maximum frame size (FSD) that it can receive. The FSD defines the maximum size of 
a frame the NFC Forum Device in Poll Mode is able to receive. FSD is expressed in number of 
data bytes included in the frame. 


Requirements 152: Frame Size for Poll Frame (FSD) 


Poll Mode Listen Mode 


12.6.1. The NFC Forum Device MUST 12.6.1.9 The NFC Forum Device MUST 
accept frames with a number of send frames with a number of data 
data bytes less than or equal to bytes less than or equal to FSD. 
FSD. 


The NFC Forum Device MUST 
resort to exception processing 
(Protocol Error) if it receives a 
frame with more than FSD data 


bytes. 

12.6.1.10 The FSD supported by the NFC 12.6.1.11 The NFC Forum Device MUST 
Forum Device MUST be FSDwmin. support an FSD equal to FSDmin. 
Refer to Appendix A.8 for the The NFC Forum Device MAY accept an FSD 
value of FSDym. less than FSDyin. 


The FSD, in terms of FSDI, is indicated in Table 74. 


Table 74: FSDI to FSD Conversion 


FSDI Oh th 2h 3h 4h 5h 6h 7h 8h  9h-Fh 
FSD (bytes) 16 24 32 140 48 64 96 128 256 RFU 
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Requirements 153: FSDI 


Poll Mode 


12.6.1.12 The NFC Forum Device MUST set FSDI greater than or equal to the value 
corresponding to FSDwin, with a maximum value of 8h. Refer to Appendix A.8 for 
the value of FSDwin. Refer to Table 74 for FSDI to FSD conversion. 


Requirements 154: Listen Mode Handling of RFU Values of FSDI 


Listen Mode 


12.6.1.13 A received value of FSDI = 9h-Fh MUST be treated by the NFC Forum Device as 
FSDI - 8h. 


The most significant nibble (b8 to b5) is used by the NFC Forum Device in Poll Mode for bit rate 
selection, as shown in Table 75 and Table 76. 


Table 75: Coding of b8 and b7 of Param 2 
b8 b7 Meaning 


Di isrENo Port = 1 


Di isrENSPoLL = 2 


Duisten-sPoLt = 4 


Duisten>poLL = 8 


Table 76: Coding of b6 and b5 of Param 2 
b6 b5 Meaning 


Drot use = 1 


Dpottsusten = 2 


DporLousten A 


kä lä OO o 


Dpottsusten = 8 
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Requirements 155: Setting the Bit Rate 


Poll Mode Listen Mode 

12.6.1.14 The NFC Forum Device MUST 12.6.1.15 The NFC Forum Device in Listen 
select bit rates compliant with the Mode MUST accept the bit rates 
bit rates proposed by the NFC selected by the NFC Forum Device 
Forum Device in Listen Mode in in Poll Mode in the ATTRIB 
its SENSB RES Response. Command, provided they comply 


with those proposed by the NFC 
Forum Device in Listen Mode in 
its SENSB RES Response. 


Param 3 
Param 3 is used for confirmation of the protocol type and is coded as specified in Table 77. 
Table 77: Format of Param 3 of the ATTRIB Command 


b8 b7 b6 b5 b4 b3 b2 bi Meaning 
0 0 0 0 0 RFU 


X X Minimum TR2 


X Ob: NFC Forum Device in Listen Mode not 
compliant with [ISO/IEC 14443] 


1b: NFC Forum Device in Listen Mode 
compliant with [ISO/IEC 14443] 


Requirements 156: Format of Param 3 of the ATTRIB Command 
Poll Mode 


12.6.1.16 The NFC Forum Device MUST set b1 to 1b, indicating compliance with 
[ISO/IEC 14443]. 


Requirements 157: Listen Mode Handling of RFU Values of b8 to b4 of Param 3 
Poll Mode 


12.6.1.17 The NFC Forum Device in Listen Mode MUST ignore and not answer an ATTRIB 
Command with b8 to b4 of Param 3 different from 00000b. 
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Param 4 
The Param 4 byte codes the DID as shown in Table 78. 
Table 78: Format of Param 4 of the ATTRIB Command 


b8 b7 b6 b5 b4 b3 b2 bi Meaning 
0 0 0 0 RFU 


Requirements 158: Format of Param 4 of the ATTRIB Command 


Poll Mode Listen Mode 

12.6.1.18 The NFC Forum Device MUST set 12.6.1.19 The NFC Forum Device MUST be 
the DID field to a value between 0 ready to receive a DID field with a 
and 14. value between 0 and 14. 


Requirements 159: Listen Mode Handling of RFU Value of DID 
Listen Mode 
12.6.1.20 The NFC Device in Listen Mode MUST ignore and not answer the ATTRIB 


command when received value of DID = 15. 


Higher layer — INF 


The Higher layer — INF field may include any higher layer Command transferable as INF field in 
the Half-Duplex Block Transmission protocol, as defined in Section 13. 


Requirements 160: Higher Layer — INF 


Poll Mode Listen Mode 

An NFC Forum Device in Poll Mode MAY 12.6.1.21 The NFC Forum Device MUST be 
include a higher layer Command in the Higher ready to receive an ATTRIB 

layer — INF field. Command with or without Higher 


layer — INF field. 


12.6.2 ATTRIB Response 


An NFC Forum Device in Listen Mode answers to an ATTRIB Command with the format 
described in Table 79. A Valid Response to an ATTRIB Command is the means for an NFC 
Forum Device in Poll Mode to verify that activation of the NFC Forum Device in Listen Mode 
has been successful. 


Table 79: ATTRIB Response Format 


Byte 2 - 2+n-1 


Higher layer — Response 
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The least significant nibble (b4 to b1) of Byte 1 contains the returned DID. 


Requirements 161: DID in ATTRIB Response 


Poll Mode Listen Mode 
12.6.2.1 |The NFC Forum Device MUST 12.6.2.2 | The NFC Forum Device MUST 
be ready to receive a DID field set the DID in the ATTRIB 
with 0 or the same value as sent Response to the same value as 
before in the DID field of the received in the DID field of the 
ATTRIB Command. preceding ATTRIB Command. 
The NFC Forum Device MAY treat a DID If the DID is not supported by the 
field with a different value as Protocol Error. NFC Forum Device, it MUST set 
the DID to 0. 


NOTE A valid answer (same DID and valid CRC_B) to an ATTRIB command is the way 
that an NFC Forum Device in Poll Mode verifies that the NFC Forum Device in 
Listen Mode has been selected successfully. 


e The most significant nibble (b8 to b5) of Byte 1 codes the Maximum Buffer Length Index 
(MBLLI). It is used by the NFC Forum Device in Listen Mode to inform the NFC Forum 
Device in Poll Mode about its Maximum Buffer Length (MBL) to receive chained frames. 
The coding of MBLI is: 


e MBLI = 0 means that the NFC Forum Device in Listen Mode provides no information 
about its internal input buffer size. 


e MBLI> 0 is used to calculate the actual internal maximum buffer length (MBL) 
calculated with the following formula: 


MBL = FSC x 281 


e The Higher layer — Response field includes the answer to the higher layer Command included 
in the Higher layer — INF field of the ATTRIB Command. 


Requirements 162: Higher Layer - Response 


Poll Mode Listen Mode 

12.6.2:3 The NFC Forum Device MUST be 12.6.2.4 The NFC Forum Device MUST 
ready to receive an ATTRIB respond with an empty Higher 
Response with or without a Higher layer — Response to an ATTRIB 
— layer INF field in response to an Command without Higher layer — 
ATTRIB Command with Higher — INF field. 
layer INF field. The NFC Forum Device MAY respond with a 


Higher layer — Response to an ATTRIB 
Command with Higher layer — INF field. 
The NFC Forum Device MAY also respond 
with an empty Higher layer — Response to an 
ATTRIB Command with Higher layer — INF 
field, indicating that the Higher layer 
Command is not supported. 
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12.7 Timing Requirements 
The Type 4B Tag platform uses NFC-B frame timing rules. 


Requirements 163: Frame Timing - Type 4B Tag Platform 


Poll and Listen Mode 


12.7.10. Commands and Responses specified in Section 12 (Type 4B Tag platform) MUST 
follow the NFC-B Technology frame timing definitions as defined in Section 5.9. 
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13 ISO-DEP Protocol 


When the NFC Forum Device, configured for Type 4A or Type 4B Tag platform has been 
activated, then during the Data Exchange Activity until device deactivation all Commands and 
Responses (i.e., the payload) are transmitted according to the Half-Duplex Block Transmission 
Protocol, as specified in this section. 


[ISO/IEC 14443] is the normative reference for this section. 


13.1 Block Format 


Data bytes transmitted in a frame are organized as blocks. A block complies with the data 
protocol layer as used in this document. 
13.1.4 Block 


Blocks consist of the SoD, the payload, and the EoD. The SoD contains the Protocol Control 
Byte, referred to as PCB and the optional DID. 


The EoD contains a two-byte checksum referred to as CRC. Input for CRC calculation is the SoD 
and the payload. 


NOTE For Type 4A Tag platform, the CRC is referred to as CRC_A; for Type 4B Tag 
platform, the CRC is referred to as CRC B. 


The block format is illustrated in Figure 30. 


Block (Data) 


SoD Payload EoD 


PCB [DID] [INF] CRC 1 CRC 2 


Figure 30: Block Format 


NOTE The terms Prologue Field, Information Field, Epilogue Field, and EDC as used in 
[ISO/IEC 14443] are referred to as SoD, payload, EoD, and CRC, respectively. 


Requirements 164: Block Length 


Poll Mode Listen Mode 

13.1.1.1 The total length of a block sent by the 13.1.1.2 The total length of a block sent by the 
Reader/Writer MUST be less than or Card Emulator MUST be less than or 
equal to FSC (FSC as specified by the equal to FSD (FSD as specified by the 
Card Emulator during the protocol Reader/Writer during the protocol 
installation). installation). 

13.1.1.3 The Reader/Writer MUST be ready to 13.1.1.4 The Card Emulator MUST be ready 
receive blocks with a length less than to receive blocks with a length less 
or equal to FSD bytes. The than or equal to FSC bytes. The Card 
Reader/Writer MUST treat as Emulator MUST treat as Protocol 
Protocol Errors blocks containing Errors blocks containing more than 
more than FSD bytes. FSC bytes. 
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13.1.2 SoD 
The SoD contains the mandatory PCB and, optionally, the DID. 
e PCB 


The Protocol Control Byte (PCB) is used to convey the information required to control the 
data transmission. The protocol defines three fundamental types of blocks: 


e J-block used to convey information for use by the application layer. 


e  R-block used to convey positive or negative acknowledgements. An R-block never 
contains an INF field. The acknowledgement relates to the last received block. 


e  S-block used to exchange control information between the Reader/Writer and the Card 
Emulator. Two different types of S-blocks are defined: 


e Waiting Time eXtension (WTX) containing a 1 byte long INF field 
e DESELECT containing no INF field. 


The format of the PCB depends on its type. The format of I-blocks, R-blocks, and S-blocks is 
shown in Table 80, Table 81, and Table 82. 


Table 80: Format of I-block PCB 


b8 b7 b6 b5 b4 b3 b2 bi Meaning 
0 0 I-block 


0 RFU 


X Chaining, if bit is set to 1b 


x DID following, if bit is set to 1b 


0 NAD following. MUST be set to 0b 


1 MUST be set to 1b 


X Block number 


Table 81: Format of R-block PCB 


b8 b7 b6 b5 b4 b3 b2 bi = Meaning 
1 0 R-block 


1 MUST be set to 1b 


x ACK, if bit is set to Ob 
NAK, if bit is set to 1b 


x DID following, if bit is set to 1b 


0 MUST be set to Ob 


1 RFU 


x Block number 


NFC Digital Protocol Page 129 


ISO-DEP Protocol 


Table 82: Format of S-block PCB 


b8 b7 b6 b5 b4 b3 b2 bi Meaning 
1 1 S-block 


x x DESELECT, if set to 00b 
WTX, if set to 11b 


x DID following, if bit is set to 1b 


0 MUST be set to Ob 


1 RFU 


0 RFU 


e DID Field 


The DID is used to identify a specific NFC Forum Device in Listen Mode. The two most 
significant bits—b8 and b7—code the power level indicator. The format of the DID field is 
shown in Table 83. See also Section 11.6.1 and Section 12.6.1. 


Table 83: Format of DID Field 


b8 b7 b6 b5 b4 b3 b2 bi = Meaning 


X X Power Level Indicator 


0 0 RFU 


X X X X DID 
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Requirements 165: DID 


Poll Mode Listen Mode 

13.1.2.4 . The NFC Forum Device in Poll 13.1.2.2 An NFC Forum Device in Listen 
Mode MUST not include a DID, Mode that does not support DID 
if the NFC Forum Device in MUST ignore blocks including a 
Listen Mode does not support DID. 
DID. 

13.1.2.3 The NFC Forum Device in Poll 13.1.2.4 An NFC Forum Device in Listen 
Mode MUST use the DID Mode that supports DID: 
negotiated during the Device e MUST respond to blocks 
Activation Activity, if the NFC containing the DID that was 
Forum Device in Listen Mode negotiated during the Device 
supports DID. Activation Activity by using 

this DID 


e MUST ignore a block with a 
DID different from the DID 
negotiated during the Device 
Activation Activity 


e MUST, in case the DID 
negotiated during the Device 
Activation Activity is 0, 
respond to a block containing 
no DID by using no DID 


Requirements 166: Power Level Indicator 


Poll Mode Listen Mode 
The Reader/Writer MAY support a power 13.1.2.5 The power level indicator MUST be 
level indicator different from 00b. set to 00b. 


Requirements 167: Handling of RFU Values of DID Field 
Listen and Poll Mode 


13.1.2.6 A received value for b6-b5 that is different from 00b MUST be treated as Protocol 
Error. 


13.1.3 Payload 


The payload consists of the optional INF field. When present, the INF field conveys either 
application data in I-blocks or non-application data and status information in S-blocks. The length 
of the payload is calculated by counting the number of bytes of the whole block minus the length 
of the SoD and the EoD. 

13.1.4 EoD 


The EoD contains the CRC. 


NFC Digital Protocol Page 131 


ISO-DEP Protocol 


Requirements 168: CRC 
Poll and Listen Mode 


13.1.4.1 A block MUST contain an EoD at the position, as indicated in Figure 30. 
For Type 4A Tag platform, the EoD MUST contain a CRC A as defined in Section 4.4. 
For Type 4B Tag platform, the EoD MUST contain a CRC B as defined in Section 5.4. 


13.2 Protocol Operation 


13.2.1 General Rules 


General rules for the Type 4A Tag and Type 4B Tag transmission protocol are described in 
Section 7. 


13.2.2 Frame Waiting Time Extension 


When the Card Emulator needs more time than the defined FWT to process the received block, it 
uses an S(WTX) request for a waiting time extension. An S(WTX) request contains a 1-byte INF 
field as specified in Table 84. 


Table 84: Format of INF Field of an S(WTX) Request 


b8 b7 b6 b5 b4 b3 b2 bi Meaning 


x x Power level indication 


X X X X X X WTXM 


e Power Level Indicator 


The two most significant bits—b8 and b7—code the power level indication. 


Requirements 169: Power Level Indication 


Poll Mode Listen Mode 
The Reader. /Writer MAY support a power level 1322. The power level indication is not 
indication different from 00b. used and the bits MUST be set to 
00b. 
e WIXM 


The bits b6 to b1 code WTXM. The WTXM is coded in the range from 1 to 59. 


The Reader/Writer acknowledges the request by sending an S(WTX) Response containing 
also a 1-byte INF field. The INF field consists of two parts that contain the same WTXM as 
received in the request (see Table 85). 
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Table 85: Format of INF Field of an S(WTX) Response 


b8 b7 b6 b5 b4 b3 b2 bi Meaning 
0 0 RFU 
X X X X X X WTXM 


Requirements 170: Handling of RFU Values of INF Field of an S(WTX) Response 
Listen Mode 
13.2.2.2 A received value for b8 to b7 that is different from 00b MUST be treated as Protocol 


Error. 


The corresponding temporary value of FWT is calculated by the following formula: 
FWT temp = FWT x WTXM 


The time FWTyemp requested by the Card Emulator starts after the Reader/Writer has sent the 
S(WTX) Response. 
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Requirements 171: Frame Waiting Time Extension 


Response block in response to an 
S(WTX) request block from the 
Card Emulator, the Reader/Writer 
MUST wait at least for FWTyemp + 
AFWT for a block of the Card 
Emulator (i.e., FDT 4 LISTEN, MAX 
equals FDTyemp + AFWT in case of 
NFC-A or FDTB,LISTEN,MAX equals 
FDT-emp + AFWT in case of NFC- 
B). 

If the Reader/Writer does not 
receive a block from the Card 
Emulator within FWTyeyp + AFWT 
+ ATeot, then the Reader/Writer 
MUST treat this as a Timeout Error. 


Between EW cu + AFWT and FWT temp + 
AFWT + ATpo,,, the Reader/Writer MAY 
accept the Response or MAY generate a Timeout 
Error. 


Poll Mode Listen Mode 
13.2.2.3 The Reader/Writer MUST be ready 13.2.2.4 The Card Emulator MUST code 
to receive an S(WTX) having a WTXM in the range from 1 to 59. 
WTXM with a value in the range 
from 1 to 59. The Reader/Writer 
MUST resort to exception 
processing (Protocol Error) on 
reception of an SCWTX) with 
WTXM set to 0 and 60 to 63. 
13.2.2.5 The Reader/Writer MUST supporta 13.2.2.6 The Card Emulator MUST code 
frame waiting time extension less WTXM such that FWTrgyp is less 
than or equal to the maximum than or equal to the maximum value 
supported FWT: of FWT: 
FWrTmq1gwp < (256 X 16/fc) X 2FWimax, FWTtemp < (256 X 16/fc) X 2FWimax, 
13.2.2.7 The Reader/Writer MUST code 13.2.2.8 The Card Emulator MUST treat a 
WTXM in the S(WTX) Response WTXM in the S(WTX) Response 
with the same value as the value of with a value different from the value 
WTXM in the S(WTX) request. of WTXM in the S(WTX) request 
as a Protocol Error. 
13.2.2.9 After sending the S(WTX) 13.2.2.10 After receiving the S(WTX) 


Response block of the 
Reader/Writer, the Card Emulator 
MUST start sending the next block 
within FWT temp (i.e., 

FDT avisten,max equals FDT yep in 
case of NFC-A or FDTsa, isrEN MAX 
equals FDTyemp in case of NFC-B). 
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Poll Mode Listen Mode 

13.2.2.11 The Reader/Writer MUST apply 13.2.2.12 The Card Emulator MUST apply 
FWT temp + AFWT only until the FWrTizwp only until the next block 
next block has been received from has been sent by the Card Emulator. 


the Card Emulator or until the 
Reader/Writer resorts to exception 
processing. 


13.2.3 Chaining 


The chaining feature allows the Reader/Writer or the Card Emulator to transmit information that 
does not fit in a single block as defined by FSC or FSD, respectively, by dividing the information 
into several blocks. 


Requirements 172: Chaining Rules 
Poll and Listen Mode 


13.2.3.1 The chaining bit in the PCB of an I-block controls the chaining of blocks. When an 
I-block indicating chaining is received, the block MUST be acknowledged by an 
R(ACK) block. 


Requirements 173: Block Sizes during Chaining 
Poll Mode 


13.2.3.2 | When the Reader/Writer sends a chain of I-blocks, each block that indicates chaining 
(i.e., all blocks of the chain except the last one) MUST have a length equal to FSC. 


Requirements 174: Last Block 
Poll Mode Listen Mode 


13.2.33 The Reader/Writer MUST not send The Card Emulator MAY treat receipt of an 
an empty I-block (i.e., without an  @™pty I-block not indicating chaining after 
INF field) not indicating chaining receipt of an I-block indicating chaining as a 
after an I-block indicating chaining Protocol Error. 
(i.e., the last block in a chain of 
blocks is not allowed to be empty). 


13.2.4 Block Numbering Rules 


This section specifies the rules for block numbering in a block of the Reader/Writer and Card 
Emulator. 
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Requirements 175: Block Numbering Rules 


Poll Mode Listen Mode 
13.2.4.1 | The block number of the 13.2.4.2 . The block number of the Card 
Reader/Writer MUST be initialized Emulator MUST be initialized to 1 at 
to 0 for the current activated Card activation. 
Emulator. 
13.2.4.3 When a Valid I-block or a Valid 13.2.4.4 When an I-block is received, the 
R(ACK) block with a block number Card Emulator MUST toggle its 
equal to the current block number is block number before sending a 
received, the Reader/Writer MUST block. 
toggle the current block number for — The Card Emulator MAY check if the received 
the current Card Emulator before block number is not in compliance with the rules 
optionally sending a block. of the Reader/Writer to decide not to toggle its 
internal block number nor to send a Response 
block. 


13.2.4655 — When an R(ACK) block with a block 
number not equal to the current Card 
Emulator’s block number is received, 
the Card Emulator MUST toggle its 
block number before sending a 
block. 

The Card Emulator MAY check if the received 

block number is not in compliance with rules of 

the Reader/Writer to decide not to toggle its 

internal block number nor to send a Response 

block. 


13.2.5 Block Handling Rules 
This section specifies the block handling rules for the Reader/Writer and the Card Emulator. 
Requirements 176: General Block Handling Rules 
Poll and Listen Mode 


13.2.5.1 The first block MUST be sent by the Reader/Writer. 


13.2.5.2  S-blocks are only used in pairs. An S(...) Request block MUST always be followed by 
an S(...) Response block except for the case where the Reader/Writer does not want to 
accept another SCWTX) Request block anymore. 
The Reader/Writer MUST respond to the first S|WTX) Request that it receives after 
sending an I-block or R-block to the Card Emulator. 


The Reader/Writer MAY stop accepting subsequent S(WTX) Requests preventing the Reader/Writer 
to be blocked by arbitrary long Card Emulator processing times. Nevertheless the Reader/Writer 
SHOULD accept a number of S(WTX) Requests to allow the normal operation to finish on the Card 
Emulator side. 
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Requirements 177: Block Handling Rules for the Reader/Writer 


Poll Mode 


13.2.5.3 | When an R(ACK) block is received with a block number not equal to the 
Reader/Writer’s current block number, then the Reader/Writer MUST re-transmit the 
last I-block if this R(ACK) block is received in response to an R(NAK) block sent by the 
Reader/Writer to notify a timeout. 


In all other cases, when an R(ACK) block with a block number not equal to the Reader/Writer’s 


current block number is received, then the Reader/Writer MAY raise the Protocol Error protocol 
exception or the Reader/Writer MAY re-transmit the last I-block. 


13.2.5.4 | When the Reader/Writer has re-transmitted an I-block two times (i.e., the same I-block 
was sent three times), it MUST be treated as a Protocol Error if an R(ACK) block with a 
block number not equal to the Reader/Writer's current block number is received.. 


13.2.555 | When an R(ACK) block is received, chaining MUST be continued if its block number is 
equal to the Reader/Writer’s current block number and the last I-block sent by the 
Reader/Writer indicates chaining. If the last I-block sent by the Reader/Writer did not 
indicate chaining, then the Reader/Writer MUST treat the R(ACK) block as a Protocol 
Error. 


13.2.5.6 ` When an R(NAK) block is received by the Reader/Writer, it MUST be treated as a 
Protocol Error. 
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Requirements 178: Block Handling Rules for the Card Emulator 


Listen Mode 


13.2.5.7 


The Card Emulator is permitted to send an S(WTX) block instead of an I-block or an 
R(ACK) block (except in the case of a retransmitted I-block or a retransmitted R(ACK) 


block). 


13.2.5.8 


When an I-block not indicating chaining is received, the block MUST be acknowledged 
by an I-block. 


If the received I-block not indicating chaining is empty (i.e., without an INF field), then the 
mandatory I-block sent MAY either be empty or contain any applicative information (e.g., error 


code). 


13.2.5.9 


When an R(ACK) or an R(NAK) block is received with a block number equal to the 

Card Emulator's current block number, then: 

e Ifthe last block was sent by the Card Emulator (i.e., the last block from the Card 
Emulator has not been acknowledged by the Reader/Writer), then the last block 
MUST be retransmitted. 

e Ifthe last block was sent by the Reader/Writer (i.e., the last block from the Card 
Emulator has been acknowledged by the Reader/Writer), then the next block MUST 
be sent. 


13.2.5.10 


When an R(NAK) block is received, an R(ACK) block MUST be sent if its block 
number is not equal to the Card Emulator's current block number. 


13.2.5.11 


When an R(ACK) block is received, chaining MUST be continued if its block number is 
not equal to the Card Emulator's current block number and the last I-block sent by the 
Card Emulator indicates chaining. 


If the last I-block sent by the Card Emulator did not indicate chaining, then the Card Emulator MAY 
treat the R(ACK) block as a Protocol Error. 


13.2.6 Exception Processing 


When errors are detected the following error handling is attempted. 


Requirements 179: Exception Processing — Card Emulator 


Listen Mode 


13.2.6.1 


The Card Emulator MUST detect Transmission Errors (frame error or EDC error) and 
Protocol Errors (infringement of the protocol rules). 


13.2.6.2 


The Card Emulator MUST NOT attempt error recovery. The Card Emulator MUST 
always stay in receive mode when a Transmission Error or a Protocol Error occurs. 


Note that an R(NAK) block is never sent by the Card Emulator. 
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Requirements 180: Exception Processing - Reader/Writer 
Poll Mode 


13.2.6.3 If a block with a Transmission Error is received after receipt of a block not indicating 
chaining (except in the case of S(DESELECT)), then the Reader/Writer MUST send an 
R(NAK) block if all of the following are true: 


e The CRC is incorrect or the frame has a parity error. 
e The block is encapsulated in a frame of at least 4 characters long. 


The Reader/Writer MUST ignore all other Transmission Errors and MUST be ready to 
process a Valid Block within a time trecovery after the end of the block with the 
Transmission Error. 

The Reader/Writer MUST send the R(NAK) block within a time tpgrgANsMIssioN 
measured from the start of the block with the Transmission Error. 

If a Transmission Error is received after sending an R(NAK) block the Reader/Writer 
MUST send another R(NAK) block until Nretry,wak consecutive R(NAK) blocks have 
been sent. If no Valid Response to all R(NAK) block is received, then the Reader/Writer 
MUST RAISE THE Transmission Error PROTOCOL EXCEPTION. 


Refer to Appendix A.9 for the values of Nretry,nak, trecovery and treTRANSMISSION- 


13.2.6.4 If a block with a Protocol Error is received after receipt of a block not indicating 
chaining (except in the case of S(DESELECT)), then the Reader/Writer MUST RAISE 
THE Protocol Error PROTOCOL EXCEPTION. 


13.2.65 If a Timeout Error occurs after receipt of a block not indicating chaining (except in the 
case of S(DESELECT)), then the Reader/Writer MUST send an R(NAK) block. The 
Reader/Writer MUST send the R(NAK) block after FWT+AFWT and before 
FWT+AFWT-+tretransmission. If a Timeout Error occurs after sending an R(NAK) block 
the Reader/Writer MUST send another R(NAK) block until Nretry,wak Consecutive 
R(NAK) blocks have been sent. If no Valid Response to all R(NAK) blocks is received 
or if the Reader/Writer has detected a time-out following Nretry,wrx + 1 consecutive 
S(WTX) Response blocks (i.e., the Reader/Writer detects three times a Timeout Error 
following an SCWTX) Response without receiving a Valid I-block or R-block from the 
Card Emulator), then the Reader/Writer MUST RAISE THE Timeout Error 
PROTOCOL EXCEPTION. 


Refer to Appendix A.9 for the values of Nretry,wrx; 
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Poll Mode 


13.2.6.6  Ifablock with a Transmission Error is received after receipt of a block indicating 
chaining, then the last R(ACK) block sent by the Reader/Writer MUST be retransmitted 
if all of the following are true: 


e The CRC is incorrect or the frame has a parity error. 
e The block is encapsulated in a frame of at least 4 characters long. 


The Reader/Writer MUST ignore all other Transmission Errors and MUST be ready to 
process a Correct Frame within trecovery after the end of the block with the 
Transmission Error. 

The Reader/Writer MUST send the R(ACK) block within tretransmission Measured from 
the start of the block with the Transmission Error. 

If a Transmission Error is received after sending an R(ACK) block the Reader/Writer 
MUST send another R(ACK) the Reader/Writer until Nretry,ack + 1 consecutive 
R(ACK) blocks have been sent. If no Valid Response to all R(ACK) blocks is received, 
then the Reader/Writer MUST RAISE THE Transmission Error PROTOCOL 
EXCEPTION. 


Refer to Appendix A.9 for the values of Nretry,ack: 


13.2.6.7 If a block with a Protocol Error is received after receipt of a block indicating chaining, 
then the Reader/Writer MUST RAISE THE Protocol Error PROTOCOL EXCEPTION. 


13.2.6.8 If a Timeout Error occurs after receipt of a block indicating chaining, the last RACK) 
block sent by the Reader/Writer MUST be retransmitted to ask for retransmission until 
Nretry,ack + 1 consecutive R(ACK) blocks have been sent. The Reader/Writer MUST 
send the R(ACK) block after FWT+AFWT and before FWT+AFWT+tretransmission: If 
no Valid Response to all R(ACK) blocks is received or if the Reader/Writer has detected 
a time-out following Nretry,wrx + 1 consecutive S(WTX) Response blocks (i.e., the 
Reader/Writer detects three times a Timeout Error following an S(WTX) Response 
without receiving a Valid I-block or R-block from the Card Emulator), then the 
Reader/Writer MUST RAISE THE Timeout Error PROTOCOL EXCEPTION. 


13.2.7 De-activation Rules 


This section lists the requirements related to the deactivation of the NFC Forum Device in Listen 
Mode. The NFC Forum Device in Poll Mode deactivates the NFC Forum Device in Listen Mode 
by sending an S(DESELECT) request block. The NFC Forum Device in Listen Mode 
acknowledges the deactivation by returning an S(DESELECT) response block. 
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13.2.7.1 


ISO-DEP Protocol 


Requirements 181: Deactivation Rules 


The NFC Forum Device in Poll 
Mode MUST deactivate the NFC 
Forum Device in Listen Mode by 
sending an S(DESELECT) request 
block. The S(DESELECT) request 


Listen Mode 


The NFC Forum Device in Listen 
Mode MUST acknowledge the 
deactivation request by sending an 
S(DESELECT) response block. 
The S(DESELECT) response 


block MUST be coded as an S- 
block as specified in Table 82. 


block MUST be coded as an S- 
block as specified in Table 82. 


13.2.7.3 13.2.7.4 The NFC Forum Device in Listen 
Mode MUST send an 
S(DESELECT) response block to 
the NFC Forum Device in Poll 
Mode within FWTpeactivation 
(refer to FWTpgacrivarioN in 


Appendix A.9. 


Following the sending of the 
S(DESELECT) request block to the 
NFC Forum Device in Listen 
Mode, the NFC Forum Device in 
Poll Mode MUST wait at least 
FWTpeactwvation for the 
S(DESELECT) response block 
from the NFC Forum Device in 
Listen Mode. 


Requirements 182: Error Handling for Deactivation 
Poll Mode 


13.2.7.5 If a Protocol Error is detected in the S(DESELECT) response block, then the NFC 
Forum Device in Poll Mode MUST RAISE THE Protocol Error PROTOCOL 


EXCEPTION. 


13.2.7.6 When a Transmission Error is detected in the S(DESELECT) response block, then 
the NFC Forum Device in Poll Mode MUST resend the S(DESELECT) request 
block until hggrgvpEsELecr Consecutive S(DESELECT) request blocks have been 
sent. The NFC Forum Device in Poll Mode MUST resend the S(DESELECT) block 
within a delay of tpetransmission Measured from the start of the SSDESELECT) 
response block containing the Transmission Error. If no valid SSDESELECT) 
response block to all SSDESELECT) request blocks is received, then the NFC Forum 
Device in Poll Mode MUST RAISE THE Timeout Error PROTOCOL 


EXCEPTION. 
Refer to Appendix A.9 for the values of Nretry,DESELECT- 


13.2.7.7 | When no S(DESELECT) response block is received within the delay 
FWTpeactivation, then the NFC Forum Device in Poll Mode MUST resend the 
S(DESELECT) request block until Nretry,peseLect Consecutive S(DESELECT) 
request blocks have been sent. The NFC Forum Device MUST resend the 
S(DESELECT) request block after FWTpeactivation and before FWTpgacrivarioN + 
tretransmission- If no valid S[DESELECT) response block to all SSDESELECT) 
request blocks is received, then the NFC Forum Device MUST RAISE THE 


Timeout Error PROTOCOL EXCEPTION. 
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13.3 Timing Requirements 


The Type 4A and Type 4B Tag Half-duplex Protocol uses Type 4A Tag Platform Timing or Type 
4B Tag Platform Timing depending if NFC-A or if NFC-B technology is used. 


Requirements 183: Timing - Type 4A and Type 4B Tag Half-duplex Protocol 
Poll and Listen Mode 


13.3.10. | Commands and Responses specified in Section 13 MUST follow the Timing 
Requirements of Type 4A Tag Platform as defined in Section 11.7 if NFC-A 
technology is used. 


13.3.1.2 | Commands and Responses specified in Section 13 MUST follow the Timing 
Requirements of Type 4B Tag Platform as defined in Section 12.7 if NFC-B 
technology is used. 
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14 NFC-DEP Protocol 


This section specifies the NFC-DEP Protocol of the NFC Forum Device. Information, when 
already defined elsewhere, have been included for readability reasons. 


[ISO/IEC 18092] is the normative reference for this section. 


14.1 Sequence Format 


NFC Forum Devices use NFC-A sequence format or NFC-F sequence format for the NFC-DEP 
Protocol, depending on the configuration. 


Requirements 184: Sequence Format - NFC-DEP Protocol 


Initiator and Target 


14.1.1.1 ` Commands and Responses specified in Section 14 (NFC-DEP Protocol) MUST be 
transmitted using: 


e NFC-A Technology sequence format, as defined in Section 4.1, if the NFC 
Forum Device is using NFC-A Technology, or 


e NFC-F Technology sequence format, as defined in Section 6.1, if the NFC 
Forum Device is using NFC-F Technology. 


14.2 Bit Level Coding 


NFC Forum Devices use NFC-A bit level coding or NFC-F bit level coding for the NFC-DEP 
Protocol, depending on the configuration. 


Requirements 185: Bit Level Coding - NFC-DEP Protocol 


Initiator and Target 


14.2.1. Commands and Responses specified in Section 14 (NFC-DEP Protocol) MUST be 
transmitted using: 


e NFC-A Technology bit level coding, as defined in Section 4.2, if the NFC 
Forum Device is using NFC-A Technology, or 


e NFC-F Technology bit level coding, as defined in Section 6.2, if the NFC 
Forum Device is using NFC-F Technology. 
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14.3 Frame Format 
NFC Forum Devices use NFC-A frame format or NFC-F frame format for the NFC-DEP 
Protocol, depending on the configuration. 


Requirements 186: Frame Format - NFC-DEP Protocol 


Initiator and Target 
14.3.1.1 Commands and Responses specified in Section 14 (NFC-DEP Protocol) MUST be 
transmitted within: 


e NFC-A Technology standard frames as defined in Section 4.3, if the NFC 
Forum Device is using NFC-A Technology, or 


e NFC-F Technology frames as defined in Section 6.3, if the NFC Forum Device 
is using NFC-F Technology. 


14.4 Data and Payload Format 


Data transmitted in a frame has the following substructure and consists of an SoD, the payload, 
and an EoD. 


The SoD contains a start byte SB (NFC-A only), followed by a length byte LEN, indicating the 
number of payload bytes. 


The payload consists of the Commands and Responses as described in Section 14.5. 


The EoD contains a two-byte checksum, referred to as CRC. Input for the CRC calculation is the 
SoD and the payload. 


The NFC-DEP Protocol data and payload format is illustrated in Figure 31. 


Data 
SoD Payload EoD 
SB (NFC-A only) LEN Byte 1 Byte 2 is Byten | CRC1 | CRC2 


Figure 31: Data and Payload Format - NFC-DEP Protocol 
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Requirements 187: Data and Payload Format - NFC-DEP Protocol 


Initiator and Target 


14.4.1.1 


If configured for NFC-A Technology, the first byte in the SoD MUST be a start 


14.4.1.2 


byte (SB) set to the value FOh. 


The SoD MUST contain a length byte LEN at the position shown in Figure 31 with 


14.4.1.3 


a value equal to n+1, where n indicates the number of bytes the payload consists 
of. 


The SoD MUST have a value between 3 and 255. The NFC Forum Device MUST 


14.4.1.4 


treat other values as a Transmission Error. 


The payload MUST follow the SoD as indicated in Figure 31. 


14.4.1.5 


The payload, i.e., Commands and Responses specified in Section 14 (NFC-DEP 


14.4.1.6 


Protocol), MUST be followed by an EoD at the position, as indicated in Figure 31. 


e The EoD MUST contain a CRC A as defined in Section 4.4, if the NFC Forum 
Device is using NFC-A Technology. CRC 1 is the LSB and CRC 2 is the 
MSB. 


e The EoD MUST contain a CRC F as defined in Section 6.4, if the NFC Forum 
Device is using NFC-F Technology. CRC 1 is the MSB and CRC 2 is the 
LSB. 


The NFC Forum Device MUST verify a checksum contained in the EoD as 


follows: 


e If the NFC Forum Device is using NFC-A Technology, then the NFC Forum 
Device MUST verify a CRC A on receipt, as defined in Section 4.4, and 
MUST treat failure of verification as a Transmission Error. 

e Ifthe NFC Forum Device is using NFC-F Technology, then the NFC Forum 
Device MUST verify a CRC F on receipt, as defined in Section 6.4, and 


MUST treat failure of verification as a Transmission Error. 


14.5 Command Set 


Payloads exchanged between NFC Forum Devices consist of Commands and Responses. 
Table 86 lists the Commands that are available to the Initiator. For each Command, the 
corresponding Response from the Target is indicated. 


Table 86: NFC-DEP Protocol - Command Set 


Initiator (Command) Target (Response) 
ATR, REQ ATR, RES 
PSL REQ PSL RES 
DEP REQ DEP RES 
DSL REQ DSL RES 
RLS REQ RLS RES 
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This section details the format of these Commands and their Responses. 


14.6 Attribute Request (ATR REQ) 


The Attribute Request Command (ATR, REQ) is used by the Initiator to activate a Target. The 
Target responds to the ATR_REQ with the Attribute Request Response (ATR. RES). 


14.6.1 ATR REQ Length 


Requirements 188: Attribute Request Length 


Initiator Target 

14.6.1. | The number of bytes of the 14.6.1.2 The Target MUST treat an 
ATR_REQ Command MUST be ATR_REQ Command with a 
less than or equal to 64. number of bytes greater than 64 as a 

Protocol Error. 

14.6.1.3 The Initiator MUST treat an 14.6.1.4 The number of bytes of the 
ATR, RES Response with a number ATR, RES Response MUST be less 
of bytes greater than 64 as a than or equal to 64. 


Protocol Error. 


14.6.2 ATR REQ Command 
Table 87 defines the ATR. REQ format. 


Table 87: ATR. REQ Format 


Byte1 Byte 2 Byte 3-12 Byte 13 Byte 14 Byte 15 Byte 16 Byte 17-17+n 


D4h 00h NFCID3, DID, BS, BR, PP, [G0 ... Gin] 
NFCID3, 


NFCID3, is the NFC Forum Device identifier of the Initiator for the NFC-DEP Protocol. 


Requirements 189: NFCID3, Format 


Initiator Target 

14.6.2.1 If the Initiator is using NFC-F 14.6.2.2 If the Target is using NFC-F 
Technology, the Initiator MUST fill Technology, the Target MUST 
Byte 3 to Byte 10 of ATR_REQ ignore an ATR_REQ with 
with NFCID2 of the Target it wants Byte 3 to Byte 10 different from 
to address. its NFCID2. 


Byte 11 to Byte 12 of ATR REQ MAY be filled 
with Any Value. 


DID, 


The Initiator Device Identification Number (DID)) is used to identify different Targets that are 
activated at one time. If multiple target activation is not used, the DID, field is set to zero. 
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Requirements 190: Initiator Device Identification Number (DID;) 
Initiator Target 


14.6.2.3 The Initiator MUST set the DID, 14.6.2.4 The Target MUST be ready to 
field to a value between 0 and 14. receive a value transmitted by the 
Initiator in the DID, field between 
0 and 14. 
The Target MAY treat a DID, field with a 
different value as a Protocol Error. 


BS, and BR, 


BS, and BR, indicate the bit rates in Active Communication mode supported by the Initiator in 
both transmission directions. The coding of BS, and BR, is specified in Table 88 and Table 89. 


Table 88: Bit Rates Supported by Initiator in Sending Direction (BS,) 


b8 b7 b6 b5 b4 b3 b2 b1 Meaning 
0 0 0 0 RFU 


X DPoLL>LISTEN =64 supported, if bit is set to 1b. 


X Drot. ,LisTEN =32 supported, if bit is set to 1b. 


x DpoLLsLisTEN =16 supported, if bit is set to 1b. 


X DPoLL>LISTEN =8 supported, if bit is set to 1b. 


Table 89: Bit Rates Supported by Initiator in Receiving Direction (BR,) 


b8 b7 b6 b5 b4 b3 b2 DI Meaning 
0 0 0 0 RFU 


X DiisrEN POLL =64 supported, if bit is set to 1b. 


x DiisrEN POLL -32 supported, if bit is set to 1b. 


X DiisrEN POLL -16 supported, if bit is set to 1b. 


X DiisrEN POLL -8 supported, if bit is set to 1b. 


Requirements 191: BS, and BR, Coding 
Initiator Target 


14.6.2.5 The Initiator MUST set b1-b4 of 14.6.2.6 The Target MUST ignore the 
the BS, and BR, field to 0000b. values. 


NOTE In this version of the document, the Active Communication mode is not supported, 
and therefore, b1-b4 of BS, and BR, are set to 0000b. 
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Presence of Optional Parameters (PP,) 


The PP, field indicates the Length Reduction field (LR) and the presence of optional parameters. 
The format of the PP, byte is specified in Table 90. 


Table 90: PP, Format 


b8 b7 b6 b5 b4 b3 b2 b1 Meaning 
0 0 RFU 


X X LR, 


0 0 RFU 


X General (Gu bytes available, if set to 1b. 


X NAD used, if set to 1b. 
The Length Reduction (LR)) bits restrict the size of the Responses (payload) of the Target. 
Table 91 defines the LR, coding. 
Table 91: LR, Coding 


b6 b5 Meaning 


Maximum payload size is 64 bytes. 


Maximum payload size is 128 bytes. 


Maximum payload size is 192 bytes. 


AH ol e 
Al oleo 


Maximum payload size is 254 bytes. 
NOTE The maximum payload size of 254 bytes for b6 b5 - 11b overrules 
[ISO/IEC 18092]. 
Requirements 192: PP Format 
Initiator 


14.6.2.7 The Initiator MUST be ready to receive Responses containing a number of payload 
bytes less than or equal to the value as specified by LR). 


The NAD bit indicates whether the Initiator uses NAD or not. 
Requirements 193: NAD 
Initiator Target 


14.6.2.8 The Initiator MUST not use NAD  14.6.2.9 The Target MUST disregard b1 of 
and set b1 of PP, to Ob. PP, 
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General Bytes (Gi) 


The General Bytes (Gi) are optional and used to provide general information. The maximum 
number of General Bytes is calculated by the maximum number of data bytes in the ATR_REQ 
Command, subtracted by the number of mandatory data bytes in the ATR. REQ Command. 


14.6.3 ATR RES Response 
Table 92 defines the ATR. RES format. 


Table 92: ATR RES Format 


Byte1 Byte2 Byte3-12 Byte13 Byte14  Byte15  Byte16 Byte17 Byte 18-18+n 
D5h Oth NFCID3; DID; BS; BR; TO PP; [G70 ... Grn] 


NFCID3+ 
NFCID3r is the NFC Forum Device identifier of the Target for the NFC-DEP Protocol. 


Requirements 194: NFCID3; Format 


Initiator Target 

The Initiator MAY treat an NFCID3; — 4.6.3.1 _If the Target is using NFC-F 

format that differs from Requirement Technology, the Target MUST fill 

14.6.3.1 as a Protocol Error. Byte 3 to Byte 10 of ATR_RES with its 

NFCID2. 
Byte 11 to Byte 12 of ATR_RES MAY be filled with 
Any Value. 
DID; 


In the DID; field, the Target returns the same value as received in the DID, field of the preceding 
ATR_REQ Command. 


Requirements 195: Target Device Identification Number (DID;) 
Initiator Target 


14.6.3.2 The Initiator MUST be ready to 14.6.3.3 In the DID; field, the Target 


receive an ATR_RES Response MUST return the same value as 
containing a DID; byte with the received in the DID, field of the 
same value as sent in the DID, preceding ATR_REQ Command. 
field of the preceding ATR_REQ 

Command. 


The Initiator MAY treat an ATR_RES 
Response containing a different DID; byte as a 
Protocol Error. 


BS; and BR: 


BS; and BRy indicate the bit rates in Active Communication mode supported by the Target in 
both transmission directions. The format of BS; and BRz is specified in Table 93 and Table 94. 
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Table 93: Bit Rates Supported by Target in Sending Direction (BS;) 


b8 b7 b6 b5 b4 b3 b2 b1 Meaning 
0 0 0 0 RFU 


X DiisrEN POLL =64 supported, if bit is set to 1b. 


x DiisrEN POLL =32 supported, if bit is set to 1b. 


x DiisrEN POLL -16 supported, if bit is set to 1b. 


X ` Dusrew-pou =8 supported, if bit is set to 1b. 


Table 94: Bit Rates Supported by Target in Receiving Direction (BR;) 


b8 b7 b6 b5 b4 b3 b2 bi Meaning 
0 0 0 0 RFU 


X DPoLL-LISTEN =64 supported, if bit is set to 1b. 


X DPoLL>LISTEN =32 supported, if bit is set to 1b. 


X DPoLL>LISTEN =16 supported, if bit is set to 1b. 


X DPoLL>LISTEN =8 supported, if bit is set to 1b. 


Requirements 196: BS; and BR; Format 
Initiator Target 


14.6.3.4 The Initiator MUST ignore the 14.6.3.5 The Target MUST set b1-b4 of 
values. the BS; and BR; field to 0000b. 


NOTE b1-b4 of BS; and BR; are set to 0000b because the Active Communication mode is 
not supported in this version of the document. 


TO 


The least significant nibble b4 to b1 of the TO field is the Waiting Time (WT) and is used by the 
Target to code the Response Waiting Time (RWT). The format of the TO field is specified in 
Table 95. Refer to Section 14.11 for the definition of the RWT. WT has a value in the range from 
0 to 14. The value 15 is RFU. 


Table 95: TO Format 


b8 b7 b6 b5 b4 b3 b2 b1 Meaning 
0 0 0 0 RFU 


X X X X WT 
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Requirements 197: TO Format 
Initiator Target 


14.6.3.6 The Initiator MUST supporta TO  14.6.3.7 The Target MUST set WT less 


indicating a WT less than or equal than or equal to WTyax. 
to WTyax. Refer to Appendix A.10 for the 
Refer to Appendix A.10 for the value of WTyax. 


value of WTmax. 


Requirements 198: Initiator Handling of RFU Value of WT 
Initiator 


14.6.3.8 A received value of WT = 15 MUST be treated by the Initiator as WT = 14. 


Presence of Optional Parameters (PP) 


The PP; field indicates the Length Reduction field (LRy) and the presence of optional 
parameters. The format of the PP; byte is specified in Table 96. 


Table 96: PP; Format 


b8 b7 b6 b5 b4 b3 b2 bi Meaning 
0 0 RFU 


X X LR- 


0 0 RFU 


x General bytes available, if set to 1b. 


X NAD used, if set to 1b. 
The Length Reduction (LR bits restrict the size of the Commands (payload) of the Initiator. 
Table 97 defines the LR; coding. 
Table 97: LR; Coding 


b6 b5 Meaning 


Maximum payload size is 64 bytes. 


Maximum payload size is 128 bytes. 


Maximum payload size is 192 bytes. 


Fl o;rs|o 


Maximum payload size is 254 bytes. 


NOTE The maximum payload size of 254 bytes for b6 b5 = 11b overrules 
[ISO/IEC 18092]. 
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Requirements 199: PP Format 
Target 


14.6.3.9 The Target MUST be ready to receive Commands containing a number of payload 
bytes less than or equal to the value as specified by LR. 


The NAD bit indicates whether the Target uses NAD or not. 


Requirements 200: NAD 
Initiator Target 


14.6.3.10 The Initiator MUST ignore b1 of 14.6.3.11 The Target MUST not use NAD 
PP. and set b1 of PP; to Ob. 


General Bytes 


General Bytes (Gy) are optional and are used to provide general information. The maximum 
number of General Bytes is calculated by the maximum number of data bytes in the ATR, RES 
Response, subtracted by the number of mandatory data bytes in the ATR. RES Response. 


14.7 Parameter Selection Request (PSL REQ) 


The PSL. REQ Command is used to switch communication parameters for the subsequent data 
exchange through the NFC-DEP Protocol. 


14.7.1 PSL REQ Command 
The format of the PSL_REQ Command is specified in Table 98. 


Table 98: Format of PSL. REQ Command 


Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 
D4h 04h DID BRS FSL 


Requirements 201: DID - PSL REQ Command 
Initiator Target 


14.7.1.1 The Initiator MUST send the same 14.7.1.2 The Target MUST accept a 
DID as in the preceding ATR. REQ. PSL REQ Command with the same 
DID as received in the preceding 
ATR REQ Command. 


The Target MUST ignore a 

PSL REQ Command with a DID 
that is different from the DID 
received in the preceding 

ATR REQ. 


The BRS byte specifies the selected bit rates for Initiator and Target, and is formatted as shown in 
Table 99. 
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Table 99: Format of BRS 


b8 b7 b6 b5 b4 b3 b2 bi Meaning 
0 0 RFU 


X X X DSI 


X X X DRI 


The DSI codes the bit rate in communication direction from Initiator to Target. The DRI codes 
the bit rate in communication direction from Target to Initiator, as specified in Table 100. 


Table 100: Coding of DSI and DRI 


b6 b5  b4(DSI) Divisor D 
b3 b2  b1(DRI) 


0 0 0 1 

0 0 1 2 

0 1 0 4 

0 1 1 8 

1 0 0 16 

1 0 1 32 

1 1 0 64 

1 1 1 RFU 


The FSL byte defines the maximum length of Commands and Responses (number of payload 
bytes), as specified in Table 101. If no PSL_REQ Command is sent, then the value exchanged in 
ATR_REQ/RES is used. 


Table 101: Format of FSL 


b8 b7 b6 b5 b4 b3 b2 bi Meaning 
0 0 0 0 0 0 RFU 


x x Length Reduction value: 
00b: Maximum payload size is 64 bytes 
01b: Maximum payload size is 128 bytes 
10b: Maximum payload size is 192 bytes 
11b: Maximum payload size is 254 bytes 


NOTE The value 254 for b2 b1 = 11b overrules [ISO/IEC 18092]. 
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Requirements 202: FSL 


Initiator 

14.7.1.3 The Initiator MUST set FSL to a 
value that defines a maximum length 
of Commands and Responses that is 
less than or equal to the minimum of 
the lengths defined by LR, and LR. 

14.7.1.4 The Initiator MUST be ready to 


receive Responses containing a 
number of payload bytes less than or 
equal to the value as specified by 
FSL. 


The Initiator MAY treat Responses containing a 
number of payload bytes greater than the value 
as specified by FSL as a Protocol Error. 


14.7.2 PSL_RES Response 


Target 


If FSL is greater than the minimum of the 
lengths defined by LR, and LR;, then the Target 
MAY treat this as a Protocol Error. 


14.7.1.5 The Target MUST be ready to 
receive Commands containing a 
number of payload bytes less than 
or equal to the value as specified by 


FSL. 
The Target MAY treat Commands containing a 


number of payload bytes greater than the value 
as specified by FSL as a Protocol Error. 


Table 102 defines the format of the PSL_RES Response. 


Table 102: Format of the PSL_RES Response 


Byte 1 Byte 2 Byte 3 
D5h 05h DID 
Requirements 203: DID - PSL RES Response 
Initiator Target 
14.7.2.1 The Initiator MUST accept a 14.7.2. The Target MUST return the same 


PSL RES Response containing the 
same DID as sent in the PSL_REQ 
Command. 

The Initiator MUST treat a PSL. RES 
Response containing a different DID 
as Protocol Error. 


DID as received in the PSL. REQ 
Command. 


14.8 Data Exchange Protocol Request (DEP REQ) 


The Data Exchange Protocol Request Command (DEP REQ) is used by the Initiator to exchange 
data with a Target that is configured for the NFC-DEP Protocol. The Target responds to the 
DEP. REQ with the Data Exchange Protocol Request Response (DEP RES). 

14.8.1 DEP REQ Command 


Table 103 defines the format of the DEP REQ Command. 
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Table 103: Format of the DEP REQ Command 


Data Exchange Protocol Header Transport Data Bytes 
Byte1 Byte2 Byte 3 Byte 4 Byte 5 Byte 6 - 6+k-1 (optional) 
(optional) (optional) 
D4h 06h PFB [DID] [NAD] [Data Byte 1] ES [Data Byte k] 


Parameter k denotes the variable number of transport data bytes. If optional bytes are not present 
in the DEP REQ Command, then the position of the subsequent bytes is adapted accordingly 
(e.g., if the DID field and NAD field are not present in the DEP REQ Command, then the first 
transport data byte is Byte 4 instead of Byte 6). 


The format of the PFB is specified in Section 14.8.3. 


Requirements 204: DID - DEP REQ Command 


Initiator Target 

14.8.1.1 Ifthe DID sent in the preceding 14.8.1.2 Ifthe DID received in the 
ATR. REQ is different from 0, the preceding ATR, REQ is different 
Initiator MUST include the same DID from 0, then: 
in the DEP. REQ Command. e The Target MUST accept a 
If the DID sent in the preceding DEP. REQ Command with the 
ATR_REQ is equal to 0, the Initiator same DID. 
MUST include no DID in the P1 The Target MUST ignore a 
DEP. REQ Command. DEP. REQ Command with a 


different DID. 


If the DID received in the 

preceding ATR_REQ is 0, then: 

e The Target MUST accept a 
DEP_REQ Command without 
DID. 


e The Target MUST ignore a 
DEP_REQ Command with 
DID. 


14.8.2 DEP_RES Response 
Table 104 defines the format of the DEP_RES Response. 


Table 104: Format of the DEP_RES Response 


Data Exchange Protocol Header Transport Data Bytes 
Byte1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 - 6+k-1 (optional) 
(optional) (optional) 
D5h 07h PFB [DID] [NAD] [Data Byte 1] ET [Data Byte k] 
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Parameter k denotes the variable number of transport data bytes. If optional bytes are not present 

inthe DEP RES Response, then the position of the subsequent bytes is adapted accordingly (e.g., 
if the DID field and NAD field are not present in the DEP RES Response, then the first transport 
data byte is Byte 4 instead of Byte 6). 


The format of the PFB is specified in Section 14.8.3. 


Requirements 205: DID - DEP RES Response 


Initiator Target 

14.8.2.1 If the Initiator sent a DID in the 14.8.2.2 If the DEP. REQ contained a DID, 
DEP REQ, the Initiator MUST the Target MUST return the same 
accept a DEP. RES Response with the DID in the DEP RES Response. 
same DID. Otherwise, the Target MUST not 
The Initiator MUST treat a DEP. RES return a DID in the DEP. RES 
Response containing a different DID Response. 


as a Protocol Error. 

If the Initiator did not send a DID in 
the DEP. REQ, a DEP RES Response 
containing a DID MUST be treated as 
a Protocol Error. 


14.8.3 Protocol Format Byte (PFB) 


The mandatory PFB is used to convey the information required to control data transmission. The 
protocol defines three fundamental types of blocks, called the Protocol Data Units (PDU): 


e Information PDU is used to convey Application Layer Data in the transport data bytes. 
Application Layer Data is information for use by the adjacent upper layer. 


e ACK/NACK PDU is used to convey positive or negative acknowledgements. An 
ACK/NACK PDU never contains transport data bytes. The acknowledgement relates to the 
last received PDU. 


e Supervisory PDU is used to exchange control information between the Initiator and the 
Target. Two different types of Supervisory PDUs are defined: 


e Timeout extensions containing one transport data byte and 
e ATN PDU containing no transport data bytes. 


The format of the PFB depends on its type. The format of Information PDU, ACK/NACK PDU, 
and Supervisory PDU is shown in Table 105, Table 106, and Table 107, respectively. 
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Table 105: PFB Coding of Information PDU 


b8 b7 b6 b5 b4 b3 b2 bi Meaning 
0 0 0 Indicates Information PDU 


x MI: Chaining, if bit is set to 1b 


x NAD following, if bit is set to 1b 


x DID following, if bit is set to 1b 


X X PNI 


The More Information (MI) bit indicates chaining, i.e., whether the current PDU contains only a 
part of a larger block of Application Layer Data that is split up into several PDUs. Refer to 
Section 14.12.2 for more details regarding chaining. 


The Packet Number Information (PNI) bit counts the number of packets sent by the Initiator to 
the Target, and vice versa, starting with 0. These bits are used for error detection during protocol 
handling. 


Table 106: PFB Coding of ACK/NACK PDU 


b8 b7 b6 b5 b4 b3 b2 bi Meaning 
0 1 0 Indicates ACK/NACK PDU 


x Ob: ACK (Acknowledged) 
1b: NACK (Not acknowledged) 


x NAD following, if bit is set to 1b 


x DID following, if bit is set to 1b 


X X PNI 


Table 107: PFB Coding of Supervisory PDU 


b8 b7 b6 b5 b4 b3 b2 bi Meaning 
1 0 0 Indicates Supervisory PDU 


x Ob: ATN (Attention) 
1b: Timeout 


x NAD following, if bit is set to 1b 


x DID following, if bit is set to 1b 


0 0 RFU 


14.8.4 Response Timeout Extension 


When the Target needs more time than the defined RWT to process the received PDU, it sends a 
Response Timeout Extension (RTOX) Request within a Supervisory PDU to the Initiator. An 
RTOX Request contains one transport data byte, as specified in Table 108. 
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Table 108: Coding of Transport Data Byte of an RTOX Request 


b8 b7 b6 b5 b4 b3 b2 bi Meaning 
0 0 RFU 


X X X X X X RTOX 


The bits b6 to b1 code the RTOX, which is coded in the range from 1 to 59. 


The Initiator acknowledges the receipt of an RTOX Request by sending an RTOX Response 
containing one transport data byte. The transport data byte contains the same RTOX as received 
in the RTOX Request. Refer to Table 109 for the format of the RTOX Response. 


Table 109: Format of Transport Data Byte of an RTOX Response 


b8 b7 b6 b5 b4 b3 b2 bi Meaning 
0 0 RFU 
X X X X X X RTOX 


The corresponding intermediate value of RWT is calculated by the following formula: 
RWT int = RWT x RTOX 
The time RWT nz requested by the Target starts after the Initiator has sent the RTOX Response. 
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Requirements 206: Response Timeout Extension 


Initiator Target 

14.8.4.1 The Initiator MUST be ready to 14.8.4.2 The Target MUST code RTOX in the 
receive an RTOX Request with an range from 1 to 59. 
RTOX containing a value in the 
range from 1 to 59. 

The Initiator MAY resort to exception 

processing (Protocol Error) on reception of an 

RTOX Request having an RTOX set to 0 and 

60 to 63. 

14.8.4.3 The Initiator MUST support a 14.8.4.4 The Target MUST code RTOX such 
response waiting time extension that RWT nr is less than or equal to 
less than or equal to the maximum the maximum value of RWT: 
supported RWT: RWTint < (256 x 16/fc) x 2WTwax, 
RW inr < (256 x 16/fc) x 2WTwax Refer to Appendix A.10 for the value 
Refer to Appendix A.10 for the of WTyax. 
value of WTwax. 

14.8.4.5 The Initiator MUST code RTOX 14.8.4.6 The Target MUST treat an RTOX in 
in the RTOX Response with the the RTOX Response with a value 
same value as the value of RTOX different from the value of RTOX in 
in the RTOX Request. the RTOX Request as a Protocol 

Error. 
14.8.4.7 After sending the RTOX Response 14.8.4.8 After receiving the RTOX Response 


PDU in response to an RTOX 
Request PDU from the Target, the 
Initiator MUST wait for RWT nt + 
ARWT for the SoD of a PDU of 
the Target. 

If the Initiator does not receive the 
SoD of a PDU from the Target 
within RWT nt + ARWT + 

AT INITIATOR, then the Initiator 
MUST treat this as a Timeout 
Error. 


Refer to Appendix A.10 for the 
values of ARWT and AT initiator: 


Between RWT wr + ARWT and RWT nr + 
ARWT + ATinitiator; the Initiator MAY accept 
the PDU or MAY generate a Timeout Error. 


PDU of the Initiator, the Target 
MUST send the SoD of the next PDU 
within RWT nr. 


14.9 Deselect Request (DSL_REQ) 


The Deselect Request Command (DSL_REQ) is used by the Initiator to deactivate a Target. The 
Target responds to the DSL_REQ with the Deselect Response (DSL_RES). 


NFC Digital Protocol Page 159 


14.9.1 DSL REQ Command 


Table 110 defines the format of the DSL. REQ Command. 


Byte 1 
D4h 


Initiator 


14.9.1.1 


NFC-DEP Protocol 


Table 110: Format of the DSL REQ Command 


Byte 2 Byte 3 (optional) 


08h [DID] 


Requirements 207: DID - DSL REQ Command 


If the DID sent in the preceding 


ATR. REQ is different from 0, the 
Initiator MUST include the same DID 


in the DSL. REQ Command. 
If the DID sent in the preceding 


ATR_REQ is equal to 0, the Initiator 


MUST not include a DID in the 
DSL_REQ Command. 


If the DID received in the 
preceding ATR_REQ is different 
from 0, then: 


e The Target MUST accept a 
DSL_REQ Command with the 
same DID. 


e The Target MUST ignore a 
DSL_REQ Command with a 
different DID. 


If the DID received in the 
preceding ATR_REQ is 0, then: 


e The Target MUST accept a 
DSL_REQ Command without 
DID. 


e The Target MUST ignore a 
DSL_REQ Command with 
DID. 


14.9.2 DSL RES Response 


Table 111 defines the format of the DSL. RES Response. 


Byte 1 
D5h 


Table 111: Format of the DSL RES Response 


Byte 2 Byte 3 (optional) 


09h [DID] 
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Requirements 208: DID - DSL RES Response 


Initiator Target 

14.9.2.1 If the Initiator sent a DID in the 14.9.2.2 If the DSL. REQ contained a DID, 
DSL. REQ, the Initiator MUST the Target MUST return the same 
accept a DSL. RES Response DID in the DSL, RES Response. 
containing the same DID. Otherwise, the Target MUST not 
The Initiator MUST treat a DSL. RES return a DID in the DSL. RES 
Response containing a different DID Response. 


as a Protocol Error. 

If the Initiator did not send a DID in 
the DSL. REQ, a DSL RES Response 
containing a DID MUST be treated as 
Protocol Error. 


14.10 Release Request (RLS REQ) 


The Initiator uses the Release Request Command (RLS_REQ) to release a Target, which 
responds to the RLS_REQ with the Release Response (RLS. RES). 


14.10.1 RLS REQ Command 
Table 112 defines the format of the RLS. REQ Command. 


Table 112: Format of the RLS REQ Command 
Byte 1 Byte 2 Byte 3 (optional) 
D4h OAh [DID] 
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Requirements 209: RLS REQ Command 


Initiator Target 

14.10.1.1 If the DID sent in the preceding 14.10.1.2 If the DID received in the 
ATR. REQ is different from 0, the preceding ATR, REQ is different 
Initiator MUST include the same DID from 0, then: 
in the RLS_REQ Command. e The Target MUST accept a 
If the DID sent in the preceding RLS_REQ Command with the 
ATR_REQ is equal to 0, the Initiator same DID. 
MUST not include a DID in the e The Target MUST ignore a 
RLS_REQ Command. RLS_REQ Command with a 


different DID. 


If the DID received in the 
preceding ATR_REQ is 0, then: 


e The Target MUST accept a 
RLS_REQ Command without 
DID. 


e The Target MUST ignore a 
RLS REQ Command with 
DID. 


14.10.2 RLS_RES Response 
Table 113 defines the format of the RLS_RES Response. 


Table 113: Format of the RLS_RES Response 
Byte 1 Byte 2 Byte 3 (optional) 
D5h OBh [DID] 


Requirements 210: RLS_RES Response 


Initiator Target 

14.10.2.1 If the Initiator sent a DID in the 14.10.2.2 Ifthe RLS_REQ contained a DID, 
RLS REQ, the Initiator MUST accept the Target MUST return the same 
a RLS_RES Response containing the DID in the RLS_ REQ. 
same DID. Otherwise, the Target MUST not 
The Initiator MUST treat an return a DID in the RLS_RES 
RLS_RES Response containing a Response. 
different DID byte as a Protocol 
Error. 


If the Initiator did not send a DID in 
the RLS_REQ, an RLS_RES 
Response containing a DID MUST be 
treated as a Protocol Error. 


NFC Digital Protocol Page 162 


NFC-DEP Protocol 


14.11 Timing Requirements 


NFC Forum Devices use NFC-A frame timing or NFC-F frame timing for the NFC-DEP 
Protocol, depending on the configuration. 


The NFC-DEP protocol uses the Response Waiting Time (RWT) for the timing requirements. 
Requirements 211: Frame Timing - NFC-DEP Protocol 
Initiator and Target 
14.11.1.1 The minimum Frame Delay Time Poll—Listen for Commands and Responses 


specified in Section 14 (NFC-DEP Protocol) MUST be set to: 


e The minimum Frame Delay Time Poll—Listen, as defined in Section 4.10.1, if 
the NFC Forum Device is using NFC-A Technology, or 


e The minimum Frame Delay Time Poll—Listen, as defined in Section 6.7.1, if 
the NFC Forum Device is using NFC-F Technology. 


14.11.1.2 The minimum Frame Delay Time Listen Poll for Commands and Responses 
specified in Section 14 (NFC-DEP Protocol) MUST be set to: 


e The minimum Frame Delay Time Listen Poll, as defined in Section 4.10.2, if 
the NFC Forum Device is using NFC-A Technology, or 


e The minimum Frame Delay Time Listen Poll, as defined in Section 6.7.2, if 
the NFC Forum Device is using NFC-F Technology. 


The Response Waiting Time (RWT) defines the time within which a Target has to send the SoD 
of its Response after the end of a Poll Frame and is calculated by the following formula: 


RWT = (256 x 16/fc) x 2"* 


where the value of WT has the range from 0 to 14. WT is included in the ATR. RES Response as 
specified in Section 14.6.3. 


For the Device Activation Activity and the Device Deactivation Activity, the following specific 
RWTs are defined: 
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RWT activation 


A specific RWT is defined for the ATR_REQ Command. For this Command, the Target starts 
sending its Response frame within RWT activation (response waiting time). Refer to Section 
14.6.2 for the definition of the ATR REQ Command. 


NOTE The response waiting time RWTactivation is introduced and defined in this 
document. 


Requirements 212: Response Waiting Time 


Initiator Target 

14.11.1.3 Following the ATR_REQ 14.11.1.4 Following the EoD of the 
Command, the Initiator MUST wait ATR_REQ Command, the Target 
at least RWTactivationtARWT for MUST wait no longer than 
the SoD of the ATR_RES Response. RWT activation before sending the 
If the Initiator does not receive the SoD of the ATR_RES. 
SoD of the ATR_RES Response Refer to Appendix A.10 for the 
within RWT activation + ARWT + value of RWT activation. 


AT initiator: then the Initiator MUST 
treat this as a Timeout Error. 

Refer to Appendix A.10 for the 
value of ARWT and ATinitiator: 


Between RWTactivationt ARWT and 

RWT activationt ARWT + AT irri TOR, the 
Initiator MAY accept the ATR_RES or MAY 
generate a Timeout Error. 


14.11.1.5 Except for the ATR_REQ 14.11.1.6 Except for the ATR. REQ 
Command, the Initiator MUST wait Command following the EoD of a 
at least RWT+ARWT for the SoD of Command, the Target MUST wait 
the Response from the Target. no longer than RWT before sending 


If the Initiator does not receive the the SoD of the Response. 


SoD of the Response from the 
Target within 
RWT+ARWT+ATinitiator: then the 
Initiator MUST treat this as a 
Timeout Error. 


Between RWT+ARWT and RWT+ARWT+ 
AT wrriaroR, the Initiator MAY accept the 
Response or MAY generate a Timeout Error. 


For NFC-F frame timing, the FDTr,risten,max defined in Section 6.7 equals RWT - 16 bd (where 
16 bd is the bit duration of the SoF). Similar for the ATR_REQ, the FDTze, isreN uAx,ATR equals 
RWT activation = 16 bd. 
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14.12 NFC-DEP Protocol Operation 


14.12.1 General Rules 


General rules for the NFC-DEP Protocol are described in Section 7. 


14.12.2 Chaining 


The chaining feature allows the Initiator and the Target to transmit information that does not fit in 
a single PDU by dividing the information into several PDUs. 


Requirements 213: Chaining Rules 


Initiator Target 

14.12.2.1 The MI bit in the PFB of an 14.12.2.2 When an Information PDU 
Information PDU controls the indicating chaining is received, the 
chaining of PDUs. When an PDU MUST be acknowledged by an 
Information PDU indicating ACK PDU or an RTOX Request. 


chaining is received, the PDU 
MUST be acknowledged by an ACK 
PDU. 


Requirements 214: Block Sizes during Chaining 
Initiator 


14.12.2.3 When the Initiator sends a chain of Information PDUs, the number of payload bytes of 
each PDU MUST be less than or equal to the maximum payload size defined by either 
the FSL byte in PSL, REQ or, if PSL_REQ has not been used, by the LR fields in 
ATR_REQ/RES. 
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14.12.3 PDU Numbering Rules 
This section specifies the rules for PDU numbering in a PDU of the Initiator and the Target. 
Requirements 215: PDU Numbering Rules 
Initiator Target 


14.12.3.1 The PNI of the Initiator MUST be 14.12.3.2 The PNI of the Target MUST be 
initialized to 00b for the current initialized to OOb. 
activated Target. 


14.12.3.8 When a Valid Information PDU ora 14.12.3.4 When a Valid Information PDU or a 


Valid ACK PDU with a PNI equal to Valid ACK PDU is received with a 
the current PNI is received, the PNI equal to the current PNI of the 
Initiator MUST increment the current Target, the Target MUST send its 
PNI for the current Target before Response with this PNI and 
optionally sending a new PDU. increment the current PNI after. 


When, having responded to a Valid 
ATN PDU directly before, a Valid 
Information PDU or a Valid ACK 
PDU is received with a PNI equal to 
the current PNI of the Target minus 
one, the Target MUST send its 
Response with the current PNI minus 
one and MUST leave the current PNI 
unchanged afterwards. 
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14.12.4 PDU Handling Rules 


This section specifies the PDU handling rules for the Initiator and the Target. 


Requirements 216: General PDU Handling Rules 


Initiator and Target 


14.12.4.1 The first PDU MUST be sent by the Initiator. 

14.12.4.2 Supervisory PDUs are only used in pairs. A Supervisory request MUST always be 
followed by a Supervisory Response. 

Requirements 217: PDU Handling Rules for the Initiator 

Initiator 

14.12.4.3 When an ACK PDU is received, if its PNI is equal to the Initiator's current PNI and the 
last Information PDU sent by the Initiator indicated chaining, then chaining MUST be 
continued. If the last Information PDU sent by the Initiator did not indicate chaining, 
then the Initiator MUST treat the ACK PDU as a Protocol Error. 

14.12.4.4 If an RTOX Request is received in response to an Information PDU or an ACK PDU, 


the Initiator MUST send an RTOX Response except for the case where the Initiator does 
not want to accept another RTOX Request anymore. 

The Initiator MUST respond to the first RTOX Request that it receives after sending an 
Information PDU or ACK/NACK PDU. 

If an RTOX Request is received in response to an NACK PDU or an ATN PDU then 
described above it MUST be treated as a Protocol Error. 


The Initiator MAY stop accepting subsequent RTOX Requests preventing the Initiator to be blocked 
by arbitrary long Target processing times. Nevertheless the Initiator SHOULD accept a number of 
RTOX Requests to allow the normal operation to finish on the Target side. 


14.12.4.5 


When a NACK PDU is received by the Initiator, it MUST be treated as a Protocol Error. 


When an ACK PDU is received with a PNI not equal to the Initiator's current PNI, then the Initiator 
MAY treat this as a Protocol Error or the Initiator MAY re-transmit the last Information PDU. 


Requirements 218: PDU Handling Rules for the Target 


Target 

14.12.4.6 When an Information PDU not indicating chaining is received, the PDU MUST be 
acknowledged by an Information PDU or an RTOX Request. 

14.12.4.7 When an ACK PDU is received, the PDU MUST be acknowledged by an RTOX 
Request or chaining MUST be continued. 

14.12.4.8 When an ATN PDU is received, the PDU MUST be acknowledged by an identical ATN 


PDU. 
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14.12.5 Exception Processing 
When errors are detected, the following error handling is attempted. 


Requirements 219: Exception Processing - Target 


Target 
14.12.5.1 The Target MUST detect Transmission Errors and Protocol Errors. 


14.12.5.2 The Target MUST NOT attempt any error recovery. The Target MUST always stay in 
receive mode when a Transmission Error or a Protocol Error occurs. 


Note that a NACK PDU is never sent by the Target. 
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Requirements 220: Exception Processing - Initiator 
Initiator 


14.12.5.3 When entering the Initiator role, the NFC Forum Device MUST allocate an error 
counter, reset to Zero. 


14.12.5.4 Ifa PDU with a Transmission Error is received, then the Initiator MUST send an NACK 
PDU if all of the following are true: 


e The CRC is incorrect or the frame has a parity error. 
e The PDU is encapsulated in a frame of at least 4 characters long. 


The Initiator MUST ignore all other Transmission Errors and MUST be ready to process 
a Valid PDU within a time tggcovenv after the end of the PDU with the Transmission 
Error. 

The Initiator MUST send the NACK PDU within a time tretransmission Measured from 
the start of the PDU with the Transmission Error. 

If a Transmission Error is received after sending a NACK PDU the Initiator MUST send 
another NACK PDU until Nretry,wack Consecutive NACK PDUs have been sent. If no 
Valid PDU to all NACK PDUs is received, then the Initiator MUST RAISE THE 
Transmission Error PROTOCOL EXCEPTION. 


Refer to Appendix A.10 for the values of trecovery; trETRANSMISSION and NRETRY,NACK: 


14.12.5.5 Ifa PDU with a Protocol Error is received, then the Initiator MUST RAISE THE 
Protocol Error PROTOCOL EXCEPTION. 


14.12.5.6 Ifa Timeout Error occurs, the NFC Forum Device MUST continue as follows. 


If the error counter equals nro,wax, then the Initiator MUST RAISE THE Timeout Error 
PROTOCOL EXCEPTION and MUST reset the error counter. 


Otherwise, the Initiator MUST increment the error counter and proceed as follows: 


e If the last PDU sent before the Timeout Error occurred was a NACK PDU, then the 
NFC Forum Device MUST send up to Nretry,wack NACK PDUs to ask for 
retransmission. The Initiator MUST send a NACK PDU before tretransmission: 


e Ifa Valid PDU is not received by any of the Nretry,wack NACK PDUs, then the 
Initiator MUST RAISE THE Timeout Error PROTOCOL EXCEPTION. 


e Otherwise, the NFC Forum Device MUST reset the error counter and continue 
processing at the point before the Timeout Error occurred. 


e Otherwise, the NFC Forum Device MUST send up to Nretry,atn ATN PDUs. The 
Initiator MUST send an ATN PDU before tretransmission- 


e Ifa Valid PDU is not received by any of the Nretry,atn ATN PDUs, then the 
Initiator MUST RAISE THE Timeout Error PROTOCOL EXCEPTION. 


e Otherwise, the NFC Forum Device MUST continue processing at the point before 
the Timeout Error occurred. 


e Refer to Appendix A.10 for the values of Nto,max, tretRansmission, aNd NRETRY,ATN. 
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A. Values 


Throughout the document symbols are used to identify the values of parameters. The actual 
values of the parameters are listed in this Appendix. For some of the parameters, a minimum and 
maximum value is defined. Other parameters are defined by a single value. 


Parameters have a value for the NFC Forum Device in Poll Mode and for the NFC Forum Device 
in Listen Mode. Unless otherwise specified, the value for Poll Mode has to be used when the 
parameter is referenced in a Poll Mode requirement. The value for Listen Mode has to be used 
when referenced in a Listen Mode requirement. 


Requirements 221: Values 


Poll Mode Listen Mode 

A.0.1 The actual Poll Mode value ofa A.0.2 The actual Listen Mode value of 
specific parameter MUST be set a specific parameter MUST be 
according to the Poll Mode set according to the Listen Mode 
value of the equally named value of the equally named 
parameter specified in this parameter specified in this 
appendix. appendix. 


A.1  NFC-A Technology 


Table 114: NFC-A Technology Poll Mode and Listen Mode Parameter Values 


Parameter Poll Mode Value Listen Mode Value Units 
Min Max Min Max 
FDTAPoLL,MiN 6780 1172 Life 
FDT REACTIVATION 5.1 5.0 ms 
GTA 5.0 ms 
tnn 1408 Life 
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A.2  NFC-B Technology 


Values 


Table 115: NFC-B Technology Poll Mode and Listen Mode Parameter Values 


Parameter Poll Mode Value Listen Mode Value Units 
Min Max Min Max 
EGTpott 0 752 0 768 l/fc 
EGTusten 0 272 0 256 l/fc 
FWTsensp 7680 4096 l/fc 
FWlyAx 14 8 - 
AFWT 16 l/fc 
ATpot 20 ms 
SFGImax 14 8 - 
ASFGT SE e l/fc 
FDTsanEAcrivATION 5.1 5.0 ms 
GTg 5.0 ms 
tnn 1408 l/fc 
TROmin 1008 1024 l/fc 
TRlwm 1254 1280 l/fc 
TR1max 3216 3200 l/fc 
TR2in,DEFAULT 6780 l/fc 
tusten,sa 1264 1424 1272 1416 l/fc 
tusten,s,2 240 400 248 392 l/fc 
tesorr 0 272 0 256 l/fc 
frot 53 1280 1416 1272 1424 Life 
tPoLL,s,2 248 392 240 400 l/fc 
frot .p 1280 1416 1272 1424 Life 
tiisrEN.E 1264 1424 1272 1416 l/fc 
FSCwmin 16 16 - 
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A.3 NEC-F Technology 


Values 


Table 116: NFC-F Technology Poll Mode and Listen Mode Parameter Values 


Parameter Poll Mode Value Listen Mode Value Units 
Min Max Min Max 
TROF, LISTEN, MIN 42 x 64 — 16 42 x 64 1l/fc 
TROF co wm 106 x 64+ 106 x 64 Life 
16 

FDT-rneacrivATION 20.4 20.0 ms 
GT: 20.0 ms 
ATpot 1 ms 
TrimEsLot 256 x 64 256 x 64 Life 
TbELAY 512 x 64 512 x 64 Life 


AA  Type1 Tag Platform 


Table 117: Type 1 Tag Platform Poll Mode and Listen Mode Parameter Values 


Parameter Poll Mode Value Listen Mode Value Units 
Min Max Min Max 

RRDDwin,sito 320 Life 

RRDDwin,sim1 384 Life 


Ab Type 2 Tag Platform 


Table 118: Type 2 Tag Platform Poll Mode and Listen Mode Parameter Values 


Parameter Poll Mode Value Listen Mode Value Units 
Min Max Min Max 

FDT t21,READ,MAX 5 4.75 ms 

FDT t21,wreite,Max 10 9.5 ms 

FD at Max 1 0.95 ms 

ATpoLt 20 ms 

PATrzrsL Man 1.00 0.95 ms 
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Values 


Ap Type 3 Tag Platform 


Table 119: Type 3 Tag Platform Poll Mode and Listen Mode Parameter Values 


Parameter Poll Mode Value Listen Mode Value Units 


Min Max Min Max 
T 256 x 16 1/fc 
ATpoit 20 ms 
ARWT 16 Life 


A.7  Type4A Tag Platform 


Table 120: Type 4A Tag Platform Poll Mode and Listen Mode Parameter Values 


Parameter Poll Mode Value Listen Mode Value Units 


Min Max Min Max 
FSDmuin 256 256 - 
FSCmin 16 16 - 
FWlyax 14 8 , 
FWT activation 71680 65536 l/fc 
AFWT 16 l/fc 
ATpott 20 ms 
ASFGT 384 x Life 
SGI 
SFGI max 14 8 - 


A.8 Type 4B Tag Platform 


Table 121: Type 4B Tag Platform Poll Mode and Listen Mode Parameter Values 


Parameter Poll Mode Value Listen Mode Value Units 
Min Max Min Max 


FSDmin 256 256 - 
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A.9  ISO-DEP Protocol 
Table 122: ISO-DEP Protocol Poll Mode and Listen Mode Parameter Values 
Parameter Poll Mode Value Listen Mode Value Units 
Min Max Min Max 

trEcoveRY 0 1152 fe 
trRETRANSMISSION 0 4096x2" 1/fe 
FWTpeactivation 71680 65536 l/fc 
DRETRY,ACK 2 5 

NReETRY,NAK 2 5 

DnETRY,wTX 2 5 

NRETRY,DESELECT 0 5 


A.10 NFC-DEP Protocol 


Table 123: NFC-DEP Protocol Poll Mode and Listen Mode Parameter Values 


Parameter Initiator Value Target Value Units 
Min Max Min Max 

WTwax 14 8 E 

ARWT 16 Life 

ATinitiator 100 ms 

RWTactivation 4096x2"* 4096x2"* Lite 

trEcoveRY 0 1280 Life 

trETRANSMISSION 0 4096x2"? Life 

NRETRY,NACK 2 5 

NRETRY,ATN 2 5 

Nto,max 2 5 
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Revision History 


B. Revision History 
Table 124 outlines the revision history of NFC Digital Protocol. 


Table 124: Revision History 


Document Revision and Change Notice Supersedes 
Name Release Date 


NFC Digital | Version 1, Final 
Protocol November 2010 
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